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ABSTRACT 



The Petite Amateur Navy Satellite (PANS AT) is a digital communications satellite 
to be used by civilian amateur radio operators. The master ground station at the Naval 
Postgraduate School performs satellite commands, displays telemetry, trouble-shoots 
problems, passes messages, and controls an open loop tracking antenna. This paper 
concentrates on the telemetry subsystem, and interpretation with an Expert System. When 
commanding the satellite, the ground station software will verify the instruction with a 
ground-based simulator before it is sent to the satellite. Telemetry is displayed in an easily 
interpretable format, so that any user can understand the current health of the satellite and 
be cued to any problems and possible solutions. Only the master ground station has the 
ability to receive all telemetry and send commands to the spacecraft; civilian ham users do 
not have access to this information. The telemetry data is decommutated and analyzed 
before it is displayed to the user, so that the raw data will not have to be interpreted by 
ground users. The analysis will use C Language Integrated Production System (CLIPS) 
imbedded in the code, and derive its inputs from telemetry decommutation. The program 
is an expert system using a forward chaining set of rules based on the expected operation 
and parameters of the satellite. By building the rules early in construction and design 
satellite, the telemetry can be well understood and interpreted after the satellite is launched 
and the designers may no longer be available to provide input to the problem. 
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r. EXPERIENCE TOUR AND LITERATURE SEARCH 



There have been several satellite programs which have used Artificial Intelligence in 
the design of the system. Their use has varied as much as the satellites. 

The first system studied was during a 6 week experience tour at the Navy Satellite 
Operations Center (NAVSOC), Pt. Mugu as part of the Naval Postgraduate School's 
curriculum. The center used to be the primary control center for the Transit navigation 
satellite constellation. Since the advent of GPS and the obsolescence of Transit, the center 
has converted to controlling several other satellites, including FleetSatCom, UFO (UHF 
Follow On), and Geosat. The center is designing a new ground station terminal which 
includes several of the features the PANS AT ground station has, including the Artificial 
Intelligence approach to analyzing the telemetry stream. Currently, due to shrinking 
funds, the A.I. analysis has stopped, but the rest of the system is becoming operational. 

The A.I. system was to be implemented with Fortran as a series of "if-then" statements. 

By using Fortran, NAVSOC had to write software that not only implemented the rules, 
but also stored the assertions, and develop the conflict resolution routines to determine 
which rule would fire. By using the C Language Integrated Production System (CLIPS), 
an Expert System shell developed by NASA the programmer only needs to concern 
himself with the knowledge base. The inference processing is inherent in the software 
background. 

Similar to the PANSAT ground station, the Integrated Satellite Control System 
(ISCS) at NAVSOC is menu driven with real time graphics for trending analysis, and 
hierarchy display models. The system controls several satellites, so it goes one step higher 
than the PANSAT ground station in the hierarchical display of information. It combines 
all telemetry points per satellite into one status when displayed. If the user wants 
amplifying information on a particular satellite, he selects it, and can view more detailed 
information about each subsystem and telemetry point. (Ref. 1) ISCS differs from the 
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PANSAT system in that it performs analysis only when a limit has been exceeded. 
Currently, this analysis is performed by the Satellite Managers, without the aid of 
software. 

An A.I. system was developed for Canada's Radarsat which could bear many 
similarities to PANSAT's use of computer reasoning. The satellite is a civilian low earth 
orbiting radar platform, so communications with the satellite are infrequent and of short 
duration. The system must operate with failed or degraded components, and short term 
power demands while the radar is transmitting exceed the power output of the solar 
panels. Depending upon the tasking of the satellite, it may be commanded more than it 
can possibly achieve. Each radar pulse will drain the batteries, and if too many missions 
are tasked, the electrical power system will need to determine the energy available. The 
power system is greatly influenced by the combination of the duration and frequency of 
eclipse, and the duty cycle of the payload. Since the power budget is well known on the 
ground, the tasking software uses rule based decisions to command the satellite without 
exceeding the power budget. Any faults not yet detected and accounted for by the ground 
station which affect the power system must then be autonomously handled by the 
spacecraft until the ground station can analyze the situation and make corrective 
adjustments in the satellite tasking procedures. The satellite must be able to operate 
autonomously up to 12 hours on a normal routine, and up to two weeks as a survival 
criterion.(Ref 2) 

A satellite workstation designed by the Aerospace Corporation for use in a militaiy 
satellite testing operations is evaluating the use of expert systems. The company decided 
that their preliminary rule based system was too limited. The project was then modified to 
capture as much of the engineering and testing experience as possible, in a way that could 
be updated. The expandable library would then allow the users a much more thorough 
analysis with an ever changing expert system. With the large expected increase in 
satellites over the next decade, the Advanced Satellite Workstation (ASW) was designed 
to reduce the cost of ground control through reduced manpower requirements. An 
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integrated support system would require fewer specialists, and the repetitive processes 
would be handled by the workstation so the engineers could do more analysis. The system 
also performed computationally intensive processes, i.e. telemetry decommutation and 
display, with an off-line computer. (Ref 3) 

The ASW supplies several features to aid satellite operators, some of which could be 
added to the PANS AT ground station as the design evolves. One feature is the ability to 
quickly access satellite logic diagrams, simulations, and pictures of the satellite with 
hypermedia presentations to aid in visualization of the flight spacecraft. The telemetry is 
displayed very similar to the PANSAT in a windows format. All telemetry is color coded, 
and windows of telemetry data are easily viewed and manipulated. All commands are also 
screen buttons and menus for quick access. During a pass, both real time and past data 
are downloaded and analyzed with the rule based expert system. Currently the system 
uses around 100 rules which determine maximum and minimum limits, rate of change, and 
combinations of rules based on the satellite design and operational experience. (Ref 3) 

The Martin Marietta Corporation designed its own system for programming and 
maintaining expert systems, the Multi Purpose Causal (MPC) Tool. This system is based 
on Lisp, and added several features that make it very easy to use. The expert shell is set 
up in a windows environment so interaction with the system is very user friendly. It also 
has tools for numerical simulation of an operating system, and fault isolation 
software.(Ref 4) 

Several expert systems have also been developed for space applications through 
NASA. The systems are designed to reduce the burdensome tasking of the flight 
controllers, who constantly monitor the Space Shuttle telemetry. The increase in 
automated systems is also desired in anticipation of Space Station requirements, where the 
telemetry tasking will be significantly increased. Before the advent of intelligent software, 
the flight controllers scanned the binary and numerical data displayed in monochromatic 
format on their computer screen. They looked for familiar normal patterns and system 
behavior, pre-defined anomalous behavior, and unknown data sets. This was performed 
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through memorization and recall of explicit patterns, so any increase in workload 
drastically reduced the flight controller's ability to properly interpret the data with 
accuracy and efficiency. The flight controllers also suffer from vision fatigue, mental 
fatigue, and boredom. When they find an anomalous data reading, they must consult 
volumes of system information to isolate the fault and find steps to alter the mission 
according to the degraded system. The automation of this process frees the controllers 
from the repetitive task of pattern searching and telemetry interpretation, and can offer 
solutions in real-time to continue the mission after a system degradation is found. All 
decisions are based upon data from the telemetry stream. The syntax of the CLIPS 
programming was set in an orderly fashion to prevent or reduce ambiguous, and redundant 
rules. All facts are represented by fields describing the Object-Attribute-Variable (0-A- 
V). By presenting all facts in the same format, the rules could be more easily integrated 
and written. The types of facts were state, timing, telemetry. The assertions were 
categorized into state, status, output. (Ref. 5) These basic formats are very similar to 
those developed in the program for PANSAT. 

The ultimate space application of an expert system is the Space Station. The number 
of systems, and amount of data will greatly outnumber any system now in use. The use of 
integrated, intelligent software will greatly reduce the number of highly trained personnel, 
and increase the productivity of the current set of flight controllers.(Re£ 6) 

The Aerospace Corporation also designed a rule based expert system for 
determining false events in the telemetry data from an earth observing sensor. This 
program used information about the health of the satellite, the sensors, data processing, 
knowledge of the problem, and physical phenomena that affect the sensors. The company 
wanted to determine if A.I. techniques were feasible for satellite data considering the large 
amount, the variety, and the complicated nature of the system. The system has to 
distinguish between operational parameters and natural phenomena, such as reflections off 
ice-capped mountains, and its differences from other noise and signal sources. The expert 
system developed was successful in maintaining system knowledge, making quick 
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decisions, and giving explanations for those decisions, which increased the user's 
confidence in the expert system. The first stage was to provide an "intelligent assistant" to 
new and inexperienced display operators. This was accomplished by providing 
information normally only available from system engineers and analysts. The final goal 
was to be able to distinguish actual signals from the satellite from noise errors caused by 
reflections office capped mountains, sea surface scattering, and other phenomena. Like 
PANS AT, the expert system is data driven. In their system, the data was imagery from 
the satellite, while the PANSAT system uses telemetry data points. The Aerospace 
Corporation found that the expert system was a viable approach to false event 
determination. It surpassed the success of traditional signal processing techniques by an 
order of magnitude. (Ref 7) 

Another project that developed an expert system was the Oceanographic Expert 
System which could potentially be used on Tactical Environmental Support System, Third 
Generation, TESS(3) stations. The program was developed to predict mesoscale feature 
movements in the Gulf Stream as an aid for weather prediction from satellite imagery. 

The use of an expert system was determined based upon the observation that human 
experts can solve problems that conventional computer techniques cannot. The rule based 
system derives its inputs from kinematic aspects of the ocean surface, and predicts the 
"state" at a later time. While the system uses a rule based program for prediction of the 
future of the changes, it relies upon a transcendental equation for the location of the Gulf 
Stream to make its calculations. The coefficients of the equation are determined by a 
neural network, another type of Artificial Intelligence, which in this case reproduces a high 
order equation. The system was coded in a combination of OPS83, C, and Fortran. The 
programming structure most resembles PROLOG of the standard AI. languages. Work is 
underway to convert the code to CLIPS. In order to run the software on different 
computer systems, it must be converted to a standard language. The conversion from 
OPS83 to PROLOG would require significant changes, while CLIPS provides an 
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alternative with other advantages, since it can be embedded in procedural code and called 
as a subroutine, and is available to all government agencies and their contractors. (Ref. 8) 
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11. ARTIFICIAL INTELLIGENCE 



The basic purpose of Artificial Intelligence is to represent knowledge in computer 
memory, capture the essential features of a problem, and make that information accessible 
to a problem solving algorithm. The system formally puts facts, rules, advice, and 
procedures into a computer where that can be manipulated to reach a final outcome. 
Knowledge representation is one of the major successes of artificial intelligence. The 
solutions to many problems depends more upon the availability of knowledge than 
sophisticated algorithms for determining solutions. The knowledge base or rules are 
computational objects and relationships that represent occurrences in the real world. (Ref 
9) The telemetry analysis will use CLIPS imbedded in the C code, and derive its inputs 
from telemetry decommutation, and files containing system configuration and satellite 
derived decisions. The program is a forward chaining set of rules based on the expected 
operation and parameters of the satellite. By building the rules during the construction 
and design of the satellite, the telemetry will be very well understood after the satellite is 
launched and the designers are no longer available to provide input to the problem. The 
code will also be well documented so that rules can be changed, added, or deleted easily. 
The rules may not have the actual operating conditions well known since the spacecraft 
has not yet been built and tested, so the operating limits may change. Another likelihood 
is that a situation arises that was not expected in the design of the satellite, so a new rule 
will have to be written to account for this situation. 

A expert system approach was used for several reasons. Knowledge can be added 
and modified easily without major reprogramming, and it has interactive capabilities for 
explanation, verification, and debugging, as well as independence of the knowledge base 
from the inference system. A rule based system can also reach many conclusions 
depending upon the data and the system. A satellite may have problems in any number of 
systems, and the analysis must find all conclusions. The set of rules is where the human 
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expert's knowledge about the operation of the satellite and its reflection in the telemetry 
data are retained. Rules can be easily constructed since most engineers and experts 
express problems in a method of "for a given situation, these actions must be performed". 
Each rule then represents an independent piece of knowledge, and new knowledge can be 
added in a modular fashion. The results of rules are assertions, the conclusions of a rule 
which add to the facts known, based upon the data. These assertions can also be called 
dynamic knowledge, since they are dependent upon the satellite telemetry, and are 
constantly changing. (Ref 10) 

The expert system also has a weakness. These knowledge representations are not 
robust. They cannot reach conclusions, or make best estimates of conclusions that were 
not known before hand. The knowledge base only represents the expert's mind and his 
experience. (Ref 10) If a new situation arises which the expert has not encountered, he 
can't possible express a rule to search for the conclusion. Even if the expert can quickly 
reach a conclusion, the analysis system won't be able to until the rule base is updated. 

This deficiency makes some A.I. experts consider the term Expert System a misnomer, 
since the rule-based system behaves more like a novice that can only perform as it is 
commanded.(Ref 11) 

The operation of most A.I. software can be broken down into two different 
categories, backward chaining and forward chaining, which depends upon the type of 
logical procedures used. Prolog is an example of a backward chaining inference engine, 
while CLIPS uses forward chaining inference. 

Backward chaining is defined as the procedure to reason from goals to facts, 
reducing goals to subgoals along the way, and hoping that all subgoals are reduced to 
facts eventually. This type of processing is also known as goal-driven search, top-down 
inference, and consequent reasoning. The steps the computational engine uses to solve 
backward chaining systems is difficult to follow. Backward chaining should be used when 
the conclusion is given, or can easily be formulated, there is a large number of rules that 
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match facts, want only one conclusion, or problem data are not available and must be 
acquired by the problem solver. (Ref 9) 

Forward chaining is defined as the process of reasoning from facts to goals, 
producing new facts along the way, and hoping the goals can be generated. This type of 
process is also known as data driven search, bottom up search, and antecedent 
reasoning. (Ref 9) 

The procedure for forward chaining is simple to understand. The processing engine 
scans the database for the set of applicable rules. As long as there are rules, and the set is 
not empty, then the final goal has not been reached. Then the computer selects from the 
set a rule whose conditions are satisfied. It applies the rule, and updates the database if 
necessary. Then the software scans the data base for applicable rules. It selects another 
rule, and continues the process until there are no rules whose conditions are satisfied. At 
this time, the search has probed all possible paths. 
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III. CLIPS EXPERT SHELL 



CLIPS can be thought of as an "expert-system shell" or "knowledge engineering 
tool" rather than a programming language. The system provides the tools needed to build 
a rule based system while keeping the inference processing part of the software hidden 
from the user. CLIPS was developed by NASA to be easily embedded in C, and to use 
syntax very similar to the standard set by Lisp. 

A programmer would want to use forward chaining over other types of software 
when his problem has certain characteristics. A forward chaining engine should be used 
when all of the facts are given, there is a large number of potential conclusions, the user 
wants to reach every possible conclusion, and it is difficult to form a conclusion. All of 
these characteristics of a forward chaining, rule based system are those desired for the 
analysis of telemetry. NASA has developed the CLIPS software after many years of 
experience with satellites, and numerous other real-time operational projects. CLIPS is 
also designed so that it can be modified very easily, without affecting the rest of the 
system, and the engineer can concentrate on the capturing of knowledge rather than the 
low level implementation of a rule system.(Ref 9) The design constraints of PANSAT 
require that a personal computer be used for the ground station and written in C and 
CLIPS is optimized for a smaller machine. Taking all of these factors into account, the 
software for building an Expert System to analyze PANSAT telemetry is CLIPS. 

A CLIPS program consists of three major components. The first is the knowledge 
base. This base is the source of system knowledge including all known facts and rules that 
determine relationships between those facts. The next important aspect is the inference 
engine. This component is the interpreter for the knowledge base, and applies the 
knowledge to the solution of actual problems. The last component is the user interface, 
which makes access more comfortable and hides all of the system complexities. There are 
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many variations in the user interface, including menus, question and answer, language, 
commands, and graphical interfaces. (Ref. 9) 

A. SEARCH STRATEGIES 

The software must search through the rule sets to reach a final conclusion. This 
search is a systematic routine that explores the problem space in search of a goal state. 
There are several different search strategies that can be used. The two most important are 
the depth first and breadth first strategy. In the simplest sense, depth first strategy means 
that the left hand side or "if side of a rule that contains the most recently asserted fact is 
at the top of the agenda list, which is the list of rules whose left hand sides are satisfied. 
The breadth first search works the opposite, it executes the rule whose left hand side uses 
asserted facts that have been asserted earliest. The simplicity strategy is merely to execute 
next the rule that has the least amount of statements on the left hand side, while the 
complexity strategy executes the rule with the most statements on the left hand side of the 
rule. The lex strategy uses the depth first search, but also uses complexity to break ties. 
The computer can also be set to execute the rules in a random order. The final strategy is 
to set the "salience" of each rule by assigning it a value indicating priority and the software 
fires the rule with the highest salience.(Ref 12) If the salience is set to control the 
program, then procedural code could just as easily perform the same function. 



B. DEPTH FIRST SEARCH 

In depth first search, the search begins at the top layer and proceeds down until the 
search can not continue any further down. At this point, the search backtracks until there 
is another possible path that goes down. The search then continues down again until once 
again it cannot continue any further down. The search then backtracks again, until 
another path down is found, and continues until all paths have been searched. The depth 
first search strategy is shown in Figure 4. 1 
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The depth first strategy can also be explained by stepping through the process as the 
computational engine would. Suppose the CLIPS rules were defined as 

If Someone is a man, then he is male. 

If someone is male, then he can be a father. 

If someone is male, then he is not female. 

If someone is a man, then he is an animal. 

If someone is an animal, then he must eat. 

If someone is an animal, then he is mortal. 

Assume that the fact is Charles is a man. 

This simple program could be implemented in CLIPS as 

(defrule man 
(man ?person)=> 

(assert (male ?person)) 

) 

(defiiile father 
(male ?person)=> 

(assert (can be father ?person)) 

) 

(defhile notfemale 
(male ?person)=> 

(assert (notfemale ?person)) 

) 

(defhile animal 
(male ?person)=> 
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(assert (animal ?person)) 

) 

(defrule eat 
(animal ?person)=> 

(assert (must_eat ?person)) 

) 

(defrule mortal 
(animal ?person)=> 

(assert (mortal ?person )) 

) 

In this case, for a depth first search, the first fact asserted is {male Charles). In the 
next layer down, the fact (can _be _ father Charles) is asserted. Since the search can go no 
deeper, then the search goes back up to the male assertion, and then the fact {not female 
Charles) is asserted. Once again, the search can go no deeper, and must backtrack all the 
way to the top, and the next fact asserted is {animal Charles). Searching under that 
assertion, then the fact {must_eat Charles) is asserted, followed by {mortal Charles). 



C. BREADTH FIRST SEARCH 

In the breadth first strategy, the search starts at the top level. It then proceeds to the 
next level and evaluates each state at the next level. The search then proceeds to evaluate 
the next level down under each node previously searched. This continues until all possible 




13 



The breadth first strategy can also be explained by carrying out the processes of the 
computer with the previous set of rules about Charles. In the first step, {male Charles) is 
asserted. The next iteration carried out is {animal Charles). Now all paths to the next 
layer under the fact that {man Charles) have been explored, so the paths from these 
assertions are then followed. Therefore, {can _be_ father Charles) is asserted, followed by 
{not Jemale Charles). Then {must_eat Charles) and {mortal Charles) are asserted. Even 
though in this case, the facts asserted were the same, the assertions occurred in a different 
order. This example shows that either strategy can search all paths, but not all programs 
can be solved regardless of search strategy. When CLIPS is loaded, the default strategy is 
depth first. 

For the program rules to analyze the telemetry from PANS AT, either search strategy 
can be used. By pre-determining the order in which key rules perform their operations, 
the program will be able to do searches on the data without complications from reading in 
the telemetry data, which is a procedural process. 

There are two reasons why the data reading routines are forced to be procedural. 
When the depth first strategy was used, the first rule in the agenda list was always the 
"read-data" rule. This caused the program to read into memory all of the data in the 
telemetry file, and assert those data points as facts. Since the telemetry file is large, the 
computer quickly runs out of RAM and must store the information on the hard disk, which 
significantly slows down the computation. By using the breadth first strategy, each data 
point can be read in singly. Each point is analyzed, and only significant information is 
retained. The data point is then retracted from the fact list, and the next data point is read 
into memory. In this way, the least amount of facts are maintained in the fact list, and 
computation time is significantly reduced. Even though the program was written to have 
only one data point read at a time, the rules still did not properly work until the rule for 
reading in the next data point and deleting the old data did not fire unless it was the only 
rule on the agenda list. By setting the salience on "read-data", the program can be run in 
either the depth first or breadth first search. 
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IV. ORBITAL DYNAMICS 



The understanding of orbital mechanics is essential to the applications of satellites in 
space. Every orbit has advantages and disadvantages over other choices. By designing a 
spacecraft around the orbit that will be used, engineers can benefit from the advantages of 
space while minimizing the negative effects of the orbit. The orbit has several profound 
effects on the design of the ground station, and the collection of telemetry. The distance 
the ground station has to communicate is directly related to the power the transmitter 
uses. The period of the orbit has a direct impact on the subsystems of the spacecraft. 
When the spacecraft enters an eclipse, it will switch from solar power to batteries. The 
satellite will also be hidden from the heat of the sun during eclipse, so the period of 
temperature fluctuations will vary with the orbit period. The orbit also determines the 
maximum amount of time the satellite will be in view of the ground station. The higher 
the altitude, the longer the satellite will be in view. The time the satellite is in view then 
determines the amount of data that can be transferred to and from the satellite. The length 
of the eclipse also determines the battery parameters. The eclipse time varies with the 
relationship between the sun and the orbital plane, and the satellite will be designed for the 
worst case when the satellite is in eclipse the longest per orbit. In this situation, the 
energy charged to the batteries during the sunlit time must be at least the same as that 
used during the eclipse, or the batteries will drain. 



A. ORBITAL THEORY 

Even though the orbit remains in a plane, its relationship to the Earth can be 
oriented in any direction. Because of this, we need a reference system that relates the 
orbit and plane of the satellite to the Geocentric Inertial reference frame as shown in 
Figure 5-1. The system that is used by the Air Force is called the Perifocal coordinate 
system. The plane of the system lies in the plane of the orbit. The X direction points at 
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the perigee of the satellite, the Y axis is in the orbital plane, 90 degrees to the X axis, and 
the Z axis lies in the direction of the angular momentum vector, h . 




Figure 5-1. Orbital Elements 

Fundamental Elements: 

Inclination, i - orients the plane in the inertial space. It is the angle between the angular 
momentum vector and the North Pole, or between the equatorial plane and the orbital 
plane. 

Right Ascension of the Ascending node, O - orients the plane in inertial space, the 
angle is measured eastward from the Vernal Equinox to the ascending intersection of the 
orbital plane and the equatorial plane. 

Argument of Perigee, © - orients the orbit in the orbital plane, the angle measured from 
the ascending node to the perigee of the orbit. 

True Anomaly,v - locates the satellite in the orbit, the angle measured in the direction of 
travel from the perigee to the location of the satellite. 



B. NEWTON’S LAWS 

The motion of all objects in the universe is governed by Newton's three laws, 
including the orbits of planets and satellites. His second law, force is equal to the rate of 
change of momentum, or 

F = ma 
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is the starting point for explaining orbital motion. For the gravitational force, the 
direction of the force is towards the other object, this shall be in the r direction as shown 
in Figure 5-2. 




Newton's Law of Gravity states that the force between two objects is proportional to 
the mass of the two objects, divided by the square of the distance between them, or 
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where p=GM. G is the universal gravitational constant 6.672 x 10 “ 

sun, p is 1.327 X lO^” ’ while for the Earth, p is 3.986x10'“* '^/i- 

By balancing the centripetal acceleration of the satellite and the force of gravity, the 
velocity of the satellite in orbit can be determined. According to Kepler's third law, the 
period of the orbit is 

T = — 

The force of gravity must be equal to the centripetal acceleration in order for the satellite 

to be in a circular orbit, so the equation becomes 

_ pm mv^ 

F = ma = ^-rr- = 

r r 

Solving for v yields 

This shows that for a higher orbit, the velocity is lower.(Ref 13) 
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C. TWO LINE KEPLER ELEMENTS 

One of the many systems used to transmit the orbital information on a satellite is to 
use the 2 line element Kepler system. This is the system used by most bulletin board 
systems that download satellite ephemeris, and is used to update the files in the ground 
station's tracking program InstaTrack. An example of the information in the data files is 

E +. 11846032+01 +.37358470-02 +.79893359+02 +.90024519+02 30490 1 94 1 
E +.44748849+02 +.71002327+02 -.273 10065+01 +.13061904-02 30490 1 94 2 

The first number on the first line is the semi-major axis of the orbit measured in 
Earth radii. The next number is the eccentricity. After that is the epoch of perigee which 
is measured in kiloseconds from midnight. The last number on the first line is the orbital 
inclination, measured in degrees. The next field is the satellite number. After that is the 
date, followed by the card or line number. The first number on the second line is the 
argument of perigee, o, measured in degrees. The next number is the right ascension of 
the ascending node, fi, also measured in degrees. The third number is the rate of change 
of the argument of perigee, measured in degrees per day. The last number of this line is 
the rate of change of the right ascension of the ascending node, also measured in degrees 
per day. The last set of numbers has the same meaning as for the first line. 

D. ORBITAL PERTURBATIONS 

If there were no forces besides gravity centered at the center of mass of the Earth, 
then the satellite would stay in the same orientation for all time. Because of many factors, 
this does not happen. The effects of the Sun, Moon, and all the planets, drag, solar 
radiation pressure, and mass asymmetry cause the orbital plane and the shape of the orbit 
to constantly change. The perturbations are any forces acting on the satellite which are 
not the uniform gravitational force of the Earth. 

The Earth is not a perfect sphere, but it is slightly flattened, making a bulge at the 
equator. The northern polar region is also flatter than the southern, making a slight pear 
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shape. The equator isn't perfectly round either, but is slightly elliptical. The primary effect 
of the asymmetrical mass of the Earth on a low orbiting circular satellite is changes in fi. 

The rate of change of the ascending node is a function of the altitude and eccentricity 
of the orbit, but is mostly affected by the inclination. An inclination of 90 degrees results 
in no change in the ascending node. Figure 5-3 is a Mathcad plot showing the relationship 
between the rate of change of the argument of the ascending node, the inclination, and 
altitude.(Ref 13) As the inclination decreases, the rate of change increases westward until 
a maximum at a zero degree inclination. For a retrograde orbit, the increase in inclination 
results in an increase in the rate of change to the East. For inclinations greater than 90 
degrees, use the positive value of the inclination minus 90 degrees. 




Figure 5-3. Orbit Precession with Respect to Orbital Inclination and Altitude 
Everything in the universe exerts a gravitational force on the satellite, but most are 
negligibly small. For satellites in a high orbit, like geosynchronous, the effects of the sun 
and the moon start to become noticeable. These mostly affect the right ascension of the 
ascending node and the argument of perigee and the forces are about five to 100 times 
weaker than the perturbing force of the Earth's oblateness. In order to make corrections 
for multi-body problem, the sun and moon are assumed to orbit the Earth, and an iterative 
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process is used to find the satellite at certain time intervals. This process is very time 
consuming and not feasible for accurately tracking large numbers of satellites. 

The physical characteristics of the launch site also place constraints on the inclination 
of the low earth orbit of the satellite. Launches from Cape Canaveral must be at least 28.7 
degrees because of the latitude of the launching nad. To the North of the launch site there 
are heavily populated areas, consequently the upper limit of the inclination is around 70 
degrees. When satellites are launched from Vandenburg, they have to go into a retrograde 
or polar orbit because of the land constraints around the base. 



E. LOW EARTH ORBITS 

Many satellites are put into a low earth orbit because for varied reasons. The fuel 
required to put a satellite into a geosynchronous orbit make the mission very expensive, 
while putting a satellite into a lower altitude saves the added weight and structure needed 
with the more fuel required. At geosynchronous orbits, the beam width of an antenna or 
other device must be very narrow to get good resolution of the Earth from the height of 
the orbit. In a low earth orbit, a larger beam width can be accepted for the satellite, or 
much greater resolution can be attained with the same instrument. The main 
disadvantages of this orbit are the increased atmospheric drag and gravitational anomalies 
that are stronger at the lower altitudes. 



F. DETERMINATION OF TIME IN VIEW 

The time that a satellite is in view can be determined from simple geometry, 
assuming that the orbit is circular and that the ground station is in the same plane as the 
orbit. As shown in Figure 5-4, a triangle can be made with vertices at the center of the 
Earth, the ground station, and the satellite position when it is E radians above the horizon. 
Two of the sides of the triangle are known, the radius of the Earth, and the radius of the 
orbit. The FCC rules state that a satellite link cannot be made less than 10 degrees above 
the horizon, so this will be used as E. 
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visible arc 




Figure 5-4, Determination of Time in View 



From the law of sines, 



sin(^-^-E) sin(^^ + E) 




The only unknown in the equation is 0, which can be solved for. The total angle in 
view is 2 X ^ . Once the total period is known, and with 0 in radians to give the partial 
fraction of 2k radians for an orbit, then the time in view is 




For the PANSAT requested altitude of 450 km., the maximum time in view is 8.6 
minutes. The time in view is a function of both the arc distance that the satellite passes 
through, and the rate at which it traverses overhead. The relationship between time in 
view and orbit altitude for an overhead pass is shown in Figure 5-5 which is determined 
using Matlab. As the altitude increases, the arc traveled increases slightly, but the greatest 
contribution to increased time in view is the longer period. 
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Figure 5-5, Plot of Time in View vs. Altitude 
In general, there are two to three passes in a row of a low earth orbiter, then the 
next pass is about ten hours later as the station rotates to under the opposite node. If one 
pass is near the maximum time overhead, the other two are significantly shorter. If the 
inclination is only 28.7 degrees, then a ground station in Monterey, CA may only have one 
period daily when communications are possible. 

G. DETERMINATION OF TIME IN ECLIPSE 

Since PANSAT will be in a low earth orbit, it will enter eclipse on every orbit. The 
eclipse is caused by the satellite entering the shadow where the Earth blocks the sun, as 
shown in Figure 5-6. The duration of the eclipse constantly changes with the seasons 
since the declination of the sun moves from plus to minus 23.45 degrees and orbit plane 
orientation as it processes. 
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Figure 5-6, Earth Shadow Intersecting Orbital Plane 
This change in the angle between the sun and the plane of the orbit determines the time of 
eclipse. The intersection of the Earth's shadow and the plane of the orbit make another 
ellipse, whose equation (Ref 1 1) is 
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Since x = r cos^and_v = r sin 0, then the equation becomes 
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To relate the angle 0 to the period, it must be found in radians. Then the total eclipse 
period can be found as 



K 

The eclipse time is the maximum when the sun is in the orbital plane, or 5 = 0 
degrees.(Ref 14) For the PANSAT in a nominal Space Shuttle orbit, this relates to an 
maximum eclipse period of 35.9 minutes. The maximum percent time in eclipse is then 
38.4%. 



23 



H. SIGNIFICANCE TO GROUND STATION AND A. I. ROUTINES 

The telemetry analysis will use only the telemetry data stream to make its decisions. 
The satellite events will be compared with the time the satellite leaves eclipse, and reenters 
sunlight as determined by the telemetry itself. This comparison will determine if there is a 
correlation between the fault and the orbit. 

The ground station must also know the ephemeris of the satellite in order to track it. 
Since the system is open loop, the antenna points to the predicted position. If the 
ephemeris is incorrect, or the ground station's time is off, then the antenna will not be 
pointing at the satellite. The time is also very important in determining the Doppler shift 
of the satellite. If the time is offby only 20 seconds, then the Doppler shift will be offby 
400 Hz. This could cause the system to not link. The ephemeris of the satellite is 
constantly changing due to unaccounted perturbations in the gravitational field, and drag 
not accounted for in the 2 line ephemeris system. The data will need to be updated 
regularly for the ground system to track PANSAT. 
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V. THERMAL CONTROL 



The heat input to a spacecraft varies widely in the space environment. When the sun 
lights on an object in space, the only method to transfer heat is in the form of radiation. 
This solar flux all but disappears when the satellite enters the Earth's shadow and only 
reflections and emissions from the Earth and moon affect the heat transfer. Since the solar 
flux is approximately 1358 W per square meter, the satellite must be able to operate in 
both extremes, from zero to maximum flux. In the sunlight, the temperature increases 
significantly as the spacecraft absorbs the sun's radiation. In eclipse, the temperature 
decreases rapidly as the satellite radiates energy to space. The thermal properties of the 
satellite must be well known before the satellite is launched to insure correct operation at 
all possible extremes of the temperature range. 



An explanation of thermal radiation can be found in quantum mechanics. A black 
body emits radiation at all wavelengths, and is modeled with Planck's Radiation Formula 



where s = power radiated per unit area of the body per wavelength, c= speed of light, 

3- 10* m/sec; h= Planck's constant, 6.62- J s; k = Boltzmann's constant, 1.38- 10'^^ 
J/K; T = temperature in Kelvins; and X= wavelength in meters. Knowing the temperature 
of the emitting body, the total amount of power radiated per unit area can be determined 
by integrating Planck's Law over all wavelengths, from zero to infinity, or 



A. LAWS OF THERMAL RADIATION 
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which results in the Stefan-Boltzmann Law 



25 






The constant o is the Stefan-Boltzmann constant, 5.67 10'* product 

of the equation has units of ^^2 • The total power radiated by the body is found by 
multiplying by the total surface area.(Ref 15) 

These laws apply only if the source of radiation is a black body, one that absorbs all 
energy at all wavelengths, and emits at all wavelengths according to the body's 
temperature, which is usually not the case in the physical world. The emission difference 
between the actual body and a black body is wavelength dependent, determined by the 
actual rate of emission compared to a black body at the same temperature. This 
comparison is called the monochromatic emissivity, The monochromatic absorptivity 
is calculated similarly, and is denoted by a^.(Ref 15) 

The same equations can be used to determine the temperature of the solar cells, 
which is important in determining the number of cells needed to power the spacecraft 
since the power varies with temperature. The solar cell determination makes a change to 
the equations so they will be applicable. The solar array uses some of the energy that is 
absorbed to make electricity, so it is not converted into heat. This is accounted for by the 
effective absorptivity as 

a^=a,-Fp-Ti. 

In this equation, the Fp is the packing factor of the solar cells on the array, r| is the solar 
cell efficiency , and a, is the solar absorptivity. (Ref 14) 

The total energy transferred by the emitter is then 

q = <r-s-f-(T‘'-'I^) 

where s is the surface area of the emitter, and T^ is the temperature the energy is radiated 
to, whether it is space or another body. Within the spacecraft, the radiation between two 
components is also dependent upon the spatial relationship between the emitters and the 
power dissipated by each component. This will account for the fact that not all energy 
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emitted by a source can be intercepted by another body. These factors are known as 
shape factor, arrangement factor, and view factor; Figure 6-1 illustrates these factors. 




The shape factor is found from 
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and the radiation from one surface to another is then 

q = <7.£-S|.F.„(T;-1^) 

The temperatures are those of the respective bodies. The energy radiated from S2 
back to SI can then be found in the same way.(Ref 15) When the configuration of a 
spacecraft is known, then this procedure must be used to determine the shape factors, and 
energy transmitted from each surface to all others within the spacecraft. When all 
equations are solved for the surface temperature, then the solution is found. There are 
different methods for determining the final temperature. The first is to use an iterative 
method, where the temperatures are assumed, and the emittance is found. Then the 
temperatures are changed to correct for the absorptance from other surfaces, and 
continues until the steady state temperatures are found. The system of equations can also 
be set up as a resistor network, where each surface is a node whose energy flow is 
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represented by a voltage, and the resistance corresponds to the shape factor, the current 
represents the radiant energy. There are software programs and tables to aid in 
determining the shape factors and temperatures. (Ref 15) 

If the satellite has an extreme temperature range, there are a couple of solutions to 
consider in the design. One solution is to design a radiator to emit excess heat to space. 
The size of the radiator is a function of its properties, and the amount of heat that needs to 
be dissipated. The ideal radiator would have minimal absorptance and maximum 
reflectance at its operating temperature. Due to exposure to the space environment, 
radiators lose some of their ability to emit heat over time, so the worst case for heating the 
spacecraft happens at the end of life. Heat is created in the spacecraft by electrical 
resistance. The equation for determining the size of the radiator is 



ri-E-a-T"* -a-S-sin(6) 

where P is the power is to be dissipated from the spacecraft, T] is the efficiency of the 
radiator due to reflections off structures, and T is the highest tolerable temperature in the 
spacecraft design, S is the solar heat input, and 6 is the incidence angle. The rest of the 
spacecraft is covered with insulation to prevent either the gain or loss of heat which is not 
be modeled or compensated for. When the radiator is not facing the sun, then the 
temperature can be found as 

T = [P/^l•E•a•Af^ 

In eclipse, the lowest possible temperature is found with r\ equal to 1.0. (Ref 14) 

Another solution to change the temperature range is to add heaters to the satellite. 
In this situation, the satellite draws energy either from the solar cells, or the batteries to 
power heaters, which convert the energy into additional heat dissipation. This translates 
into a higher spacecraft temperature. 
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B. THERMAL CONTROL OF PANSAT 



In determining the thermal characteristics of PANSAT, there are several factors that 
are a given. The heat input of the sun in well known, as well as the albedo of the Earth 
and moon. The solar panels which cover the majority of the spacecraft also have a known 
emissivity and absorptivity. Once the spacecraft configuration and components have been 
determined, and the process of finding the thermal balance of the system can begin. 

Due to the limited power margin, the thermal control of the spacecraft will be 
passive. The solar cells and the open comers will absorb the heat as well as transmit heat 
to space. The major energy dissipation will come from the batteries, the digital computer, 
and the communications receivers and transmitters. 

Once a thermal model of the spacecraft can be programmed, then the operational 
limits of the components of the spacecraft will be known. The thermal range of the 
satellite will be well modeled and tested before launch. From preliminary analysis 
performed by Professor Kraus of the Naval Postgraduate School, the satellite will not 
have a problem with overheating. 



C. THERMAL DECISIONS 

The Artificial Intelligence decisions of the thermal control system will only be able to 
check on the operation of the system since it is totally passive. The only possible 
corrections for a passive system once it is in orbit will be either to shut down systems to 
cool off the spacecraft, or to use more of the systems to increase the temperature. In 
PANSAT, the only system that can be controlled to have an effect on the temperature of 
the satellite will be the communications subsystem. If the transmitter gets too hot, then 
the Digital Control System logic may be set up to not transmit. This will cause the energy 
to be dissipated in other subsystems. Another possibility is that the attenuation level on 
the transmitter can be increased, so not as much energy is transmitted, and therefore, less 
heat is generated. On the other hand, if it gets too cold, it can constantly transmit to heat 
up the spacecraft. This solution runs into the problem of the spacecraft not having enough 
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power margin in the batteries to allow constant transmissions throughout an eclipse. The 
redundancy of systems on board can also help in the thermal control. If a subsystem is 
having temperature problems, the alternate can be selected which does not appear to have 
the same dilemma. Operations can also affect the temperature of the batteries. If the 
batteries are overheating, and they are being fully charged, then a trickle charge could be 
used. Instead of possible overcharging the batteries, they will remain charged, but won't 
convert excess energy into heat. 
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VI. POWER SYSTEM 



The design of the power system for PANSAT has taken a different course than for 
the typical satellite. Rather than the payload determining the amount of power that is 
required of the system, the physical dimensions and design of the satellite restrict the size 
of the solar panels, and thereby determine the total power available. The satellite will have 
17 solar panels, each 7.125 inches square, capable of producing 6.12 Watts each at 15.82 
volts at AMO and 28° C.(Ref 16) After much deliberation, the power storage will use X- 
rayed and intensely inspected commercial Nickel Cadmium (NiCad) batteries instead of 
space qualified cells. This greatly reduces the total cost of the power system, and has 
proven effective in other amateur satellite designs. 

The power constraints on the satellite have left very little margin for error. The 
power system is also generally the one that gives the satellites the most problems if they 
are poorly designed. The success of the entire satellite rests upon the power that it can 
produce, and fluctuations can cause havoc in other subsystems. The power system must 
be able to switch from external solar power to internal battery power without major power 
spikes, or fluctuations. Since the period is on the order of 90 minutes, the power system 
will be continually cycling between all modes of operation. 



A. SOLAR ARRAY DESIGN 

In designing the solar arrays, PANSAT is limited by the size of its panels that the 
solar cells will be mounted on. The panels are designed by Spectrolab, Inc., and meet the 
specifications determined by the Space Systems Academic Group. Since a low Earth orbit 
is not a harsh radiation environment, solar cells do not need to have exceptional resistance 
to radiation. The total radiation dose over the lifetime of the satellite as determined by 
Spectrolab Inc. is a fluence of 1.80 x 10*’ 1 MeV equivalent electrons. A fused silica 
coverslide of 30 mils thick will block all of the high energy protons and offer added 



31 



protection during construction, testing, and launch operations. The cell chosen is a Series 
6700, back surface field, back surface reflector, 10 ohm which is 1.92 cm. by 4.00 cm. At 
the beginning of life, (BOL), the cell characteristics are open circuit voltage (Voc) 605 
mV, and short circuit current (Isc) 319 mA. There are several factors that degrade the 
solar cells over the lifetime of the satellite. The first factor is a darkening of deposits on 
the fused silica coverslip and the adhesive used to attach the coverslip to the solar cell. 

This causes a degradation of the cell short circuit current less than 1%. On short duration 
missions, Spectrolab assumes micrometeorites cause little or no power loss so the total 
loss was assumed to be .98% for both factors. The radiation also causes reduced 
efficiency within the solar cells. Over the lifetime of the satellite, the predicted end of life 
(EOL) values are predicted to be .965 of the BOL volts at maximum power (Vmp), and 
.978 of the BOL amps at maximum power (Imp). There is also a panel wiring loss of .017 
volts which reduces the usable power fi-om the solar cells. Taking all of these factors into 
account makes the EOL performance 21.67 Watts at 15.27 volts, when the satellite is in 
the most favorable attitude. (Ref 16) The current of a solar cell falls off as the cosine of 
the angle the sun makes perpendicular to that cell, which in turn makes the panel power 

drop. The four sides are 45° off of the side facing the sun, so the power of each is ^/2 
times the power of the side facing the sun. Adding all sides together, the total power is 

then ^1 + '^^2 the maximum power of one side. The EOL values assume summer 

solstice solar flux, 28° C and 90° incidence angle to one of the faces with four adjacent 
panels being partially lit. The solar panel power is reduced by diode losses before the 
satellite can use that power on the spacecraft electrical bus. 

The solar array temperature found in the thermal control analysis, with the 
temperature coefficient for current, ttj, and voltage, tty, are used to verify the panel 

characteristics. With these factors, the cell current at the EOL can be found using 

! = [!.,+«, •(T-25)].K,K„.K,. 
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In this equation, T is the temperature of the cells, is the design factor for assembly 

losses in current, is the factor for environmental degradation, and Kj is the solar 
intensity factor. The temperature of the cells will be the lowest when the satellite leaves 
eclipse, so this is when the high power point can be expected. The voltage requirements 
of the bus must also be met. The voltage per cell is given by 

V = [v,-AV + a,(T-25)]-K, 

where AV is the panel wiring loss per cell, and is the radiation degradation. The 
number of cells in series can then be found by 

^ _ bus voltage + bus voltage drop 
® cell voltage 

The solar panels are then connected in parallel to the solar bus, which powers the 
electrical system bus and charges the batteries. The same equations are used to insure that 
the power requirement will be met during the winter solstice when the solar flux is higher, 
which raises the cell temperature, which has an effect on the total power. (Ref 14) 



B. DESIGN OF BATTERY 

The design of the battery cells is based upon a solar cell output of 15.27 Volts, and a 
battery voltage at least 1 1 volts. The depth of discharge for the batteries, DOD, is an 
extremely conservative 10%, and the EOL voltage, Vd, for a fully charged battery is 
expected to be 1 .3 volts per cell. According to the equation 

Vdb = (N - 1) Vd - Vdd, 

the number of cells is 10 when the voltage drop of the bypass diode, Vdd is .7 V. At the 
EOL, the actual bus voltage will be 12.3 volts assuming no cells fail, since (N-1) takes 
into account that one of the cells may short circuit. The required cell capacity was found 
by using 
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Vdb'DOD’ 

where P is the power required from the batteries, and t is 36.6 min. for a Shuttle orbit. For 
PANSAT, 5 amp-hr batteries have been selected. 

The next step is to determine the power required to charge the batteries during the 
solstice and equinox seasons. Using C/15 for charging when in a maximum eclipse 

orientation, and a current of .33 amps, the power required to charge the batteries is 
Khrg - ct4rrent- voltage . Assuming a charging efficiency of 90%, the time to recharge 

from 
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is 85.9 minutes. This time to recharge the batteries is more than the time in sunlight per 
orbit, so the satellite will not be able to operate at full capability. (Ref 14) By combining 
the time to recharge equation, with the eclipse and period equations, the relationship 
between the orbit and the electrical system becomes. 
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For the full satellite capabilities, the satellite orbit would have to be 1,602 km. in order for 
the batteries to be able to recharge fully every orbit. If the orbit is set at 450 km., then 
the eclipse power consumption would have to be less than 7.28 W. 
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C. BATTERY CIRCUITS 

The battery circuits for operating the power system are controlled by signals from 
the Digital Control System (DCS), shown in Figure 6-1 . When the DCS sends a signal to 
enable any of the charge circuits, it controls the current through the transistors which then 
allow current to flow to or from the battery. 



Current 




Figure 6-1, Electric Power System Block Diagram 



When the satellite is in the sun, the electrical bus voltage will be higher than the 
battery voltage, so the diodes prevent the batteries from charging directly off the power 
bus, as can be seen in Figure 6-2. Instead, the DCS senses the power voltage and current, 
and determines that the satellite is in the sun, and the batteries can be charged. When the 
DCS notices that the bus voltage is lower than the power bus, then the batteries are 
powering the electrical bus, and the charge circuitry is commanded "off'. 
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The battery charging system also has a trickle charge capability shown in Figure 6-3. 
In the present design, this will only be used when the cells are completely dead. If the 
batteries have no or very little voltage, as is expected when the satellite is jettisoned from 
the launch platform, a fast charge can damage the batteries. The trickle charge is used to 
charge the batteries until they can be safely charged at the full rate. 



Solar Panel Bus 




Figure 6-3. Battery Trickle Charge Circuit 



The batteries must also be periodically drained to reduce the memory effect that 
plague NiCad batteries. If the batteries are not reconditioned, then they eventually lose 
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the ability to fully charge. This is prevented by draining the batteries through resistors to 
ground, see Figure 6-4. Since the batteries are designed so that each one can power the 
spacecraft during eclipse, the cell reconditioning can occur over several orbits and one set 
of cells is reconditioned at a time. The interval to recondition the batteries is a function of 
the depth of discharge, and the information is provided by the supplier. 




Figure 6-4. Battery Discharge Circuit 



There may also be problems during the sunlight operations. There is a significant 
drain on the power system when the communications system is working. If the solar cells 
are not producing enough power run the satellite and transmit, then the batteries will 
supply the extra current needed to operate the system. 

There are a couple of possible reasons why the spacecraft would operate in the 
negative power margin region. The first is that the bottom panel without a solar panel 
may be predominantly facing the sun. In this attitude, the spacecraft receives significantly 
less power than for which the system is designed. The power system design assumes that 
at least the average overall power is available at all times. Almost any orientation and spin 
axis that the satellite takes on after ejection will have the possibility that the power margin 
will be negative at some time. If in sunlight, the satellite will also probably be negative on 
the power budget only during transmission. Using all satellite capabilities during eclipse 
draws more power than can be recharged during the next sunlit period, so the operational 
characteristics of the satellite must be reduced account for this power loss. 
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Depending upon the severity, and the number of occurrences of power problems, the 
power budget could be a major obstacle, or a minor inconvenience. If the power budget is 
not significantly draining the batteries during the charge cycle, then there may be no 
corrective action needed. It could very well be that the satellite only goes into a negative 
power budget when the blank panels is facing the sun, and the satellite is transmitting. 
Depending upon the attitude of the spacecraft, and the duty cycle of the communications, 
this may occur very seldom. On the other hand, the satellite could have a spin axis and 
attitude where its bare panel faces the sun during a significant part of the orbit. In this 
case, drastic measures may have to be taken. 

Since the satellite can sample and read the solar cell telemetry at will, the satellite 
could only transmit when it reads enough current from the solar cells to power the 
transmitting spacecraft. Another conclusion could be to not transmit at night, during 
eclipse. This would keep the batteries as highly charged as possible, so that they could 
supplement the solar panels during daytime transmissions. 

From the manufacturers documentation, the relationship between battery voltage, 
temperature, and load can be determined when the battery is fully charged. Since the load 
on the batteries can be determined from battery current telemetry, and the voltage and 
temperature are also known, it can be determined if the batteries are fully charged. By 
linearizing the suppliers plots of voltage and temperature, the equation of a line will 
determine if the batteries are at or above the voltage threshold for a given temperature. If 
so, the rule determines that the batteries are fully charged. 

There are a couple reasons why the battery voltage may be too low. As the battery 
drains, and its temperature changes, the voltage will vary constantly. The lower the 
temperature, and more drained the battery is, the lower the voltage will be. If the power 
margin is such that the batteries are not fully charged as the satellite enters eclipse, then as 
the batteries drain, their voltage may drop below limits. The batteries also have a memory 
effect so that they do not work as well after they have been used and not completely 
discharged. 
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A high battery voltage must be caused by the spacecraft power system since a 
battery's voltage is limited by the potential of the chemical reaction within the batteiy. The 
charging circuit on the satellite uses the solar cell bus to supply excess power to the 
batteries for charging. The electrical power system will charge the batteries at a full 
charging rate at all times. It is expected that with the satellite's low power margin that the 
current flow will be low and voltage within limits. 

Depending upon the spacecraft's attitude, it may receive more power than expected, 
which could in turn lead to excess heat in the batteries. The battery temperature is closely 
tied with the battery voltage. As in the high voltage case, a high temperature could be 
caused by over charging the batteries, or charging them too fast. 

The bus voltage is directly tied to the battery charging rate, so if the bus voltage is 
out of limits, the satellite should trickle charge the battery to limit the charging current 
flow. A high transmitter bus voltage is also directly tied to the electrical power system 
bus, so there is most likely a problem in the overall power system. 

When the satellite first comes back into the sun, the solar cells are at their lowest 
temperature, and highest voltage. As the cells heat up, they do not produce as much 
power. 
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VII. SATELLITE CONFIGURATION 



The satellite has several redundant subsystems, shown in Figure 7-1, so the overall 
probability of a successful mission life are greatly increased. The satellite has only one 
power source, the solar cells, which would limit or end the satellite operational life if 
problems occur. The power can be stored in either battery since each can operate the 
satellite individually if need be. There will also be two Digital Control Systems (DCS), 
multiplexers, mass storage units, transmitters, and radio frequency sections. There is only 
one antenna system, which is another area of single point failure. 




Figure 7-1, Satellite Configuration Block Diagram 



The satellite configuration will be a major aid in determining satellite problems. All 
major subsystems can be switched to isolate faulty boards. If any fault is detected that 
cannot be corrected, or adjusted, then the system can be switched. Even the DCS can be 
switched without losing the telemetry file in the mass storage unit, so the ground can 
verify the satellite's decision. The ground station will have very little control over board 
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temperatures and power consumption. If a temperature limit in the transmitter board is 
exceeded, the power out and amount of transmissions can have an impact on the 
temperature readings. The other subsystems do not have that luxury, and will have to be 
switched before they cause system failure. 
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VIII. CLIPS TELEMETRY ANALYSIS RULE SET 



The CLIPS rule set for analyzing the telemetry file can be divided into four 
categories of rules. The first set of rules reads all files that the program uses, and changes 
the data into asserted facts. The second set of rules does limit checking on the telemetry 
values, while the third set is the operational rules at determine if the satellite is properly 
operating. The last set of rules writes all knowledge about the facts into output files, 
which can then be read by other routines and displayed to the user. 

The first set of rules currently reads in three files. The first two are the stored 
telemetry file, and the current telemetry file. These two files are exactly the same in 
format, the only difference is that the stored telemetry file contains all data recorded since 
the last telemetry download, so there is significantly more data than in the current 
telemetry file, which only contains the most recent telemetry reading. The format of the 
telemetry needs to be converted from the binary format that it comes from the satellite into 
an ASCII data file that the CLIPS software can interpret. Each telemetry reading will be 
divided into sets of data. The first line in the telemetry set must be the time tag for the 
following data. All other data can be in any order and the rules will still work properly, 
which is one of the advantages of A.I. All lines must also be in a format that the program 
can read in logically. The first field is the telemetry point name. The second field is the 
number of data values that this telemetry point has. The rest of the line is the data points 
associated with that telemetry point. The number of data readings must equal the second 
field, or the program will not work properly. Each field and data point is separated by a 
space. The first couple of lines of a telemetry file may be as follows. 

time 1 41564 
batcur 2 10 10 
cellcur 1 0 

cell 17 25 30 25 25 30 -25 -17 -30 25 25 80 125 25 30 25 25 30 
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The first line is the time tag. There is only one time, so the next field is " 1 ", 
followed by the time the telemetry was read. There are two battery current reading so 
after the telemetry point name "batcur" is a "2", followed by the two measurements. The 
same format continues through the file. When a data point is read, it is asserted as (tel 
subsystem sensor_number value time), which is used by all other rules. 

The second file to be read is the configuration file. This file contains the 
configuration that the ground station thinks the satellite is in. This file's format is as 
follows. 

rxset 1 
txset 2 
modeset 1 
attenset 4 
dcsset 1 
verset 4 

The format for this file is simply the subsystem, and the one operating. This file may 
be in any order, as long as each line follows the same format. Upon launch, this file will 
be in the default configuration which the satellite should power up in. Whenever the 
spacecraft is commanded to change subsystems, this file will be updated to reflect the 
commanded change. 

The satellite will have two more files that have not yet been fully defined. The first 
is the Event Logger File. This file will contain the information that the satellite decided is 
pertinent as an anomalous event which requires action. The commands that the satellite 
has received or decided itself and executed will be stored in the Command Logger File. 
When the parameters from this file are compared with the telemetry, the software will 
decide if there has been a change in configuration, and then determine if it agrees with the 
satellite's decisions through analysis of the telemetry. There will be two more routines 
developed to read in the event logger and the command log when the two systems are 
better defined. 

The limit checking routines determine if the telemetry values are outside of the 
expected operating ranges. If a point does lie outside of the expected parameters, then the 
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rules will make assertions concerning the fact, offer corrective action, and determine the 
telemetry color that should be displayed to the user. The rules take the worst case, and 
only present those color schemes to the user at the top level. The format for an out of 
limit reading is (pt subsystem sensor_number problem time). The decisions are stored as 
facts in (dec decision_made) format. These rules also assert the telemetry subsystem 
colors as (color subsystem sensor_number red_or_yellow) and (color category 
red_or_yellow). As rules are added, using these formats will make them compatible with 
the rest of the rule set. 

The next set of rules check on the operations of the satellite. These include 
determining when in the orbit a point first went out of limits. Another possibility is that a 
telemetry point is going out of limits not constantly, but during each orbit. The 
temperatures and voltages fluctuate depending upon the time in the sun. The analysis 
routines look for the first time a limit is exceeded per orbit, and can determine if the point 
is staying out of limits at all times. Other rules determine the highest and lowest values of 
each point in the telemetry file for output to the user, and check on system operations. 

This should give the user an idea of the long term trends of the satellite data. Even though 
the data points may not be breaking any limits, by looking at only the highest value per 
orbit, one can tell of the trend is increasing such that at some time in the future, it will 
exceed one of the limits. If the data is assumed to be increasing at a linear rate, then the 
slope of the line can predict when the satellite may exceed its limits. On the other hand, if 
the long term trend is that the high values are staying constant or decreasing, then there is 
little likelihood that the limits will be exceeded. The rules check on the power system 
margin to determine if battery power is supplementing the solar cells during sunlight. 

These rules are still under development and are an area where much more can be added. 

As the system gets more fully defined and tested, more operational rules can be written to 
analyze telemetry. 

The last set of rules write all conclusions to files so that the information may be 
presented to the user. The first files are the color files. All colors are assumed to be green 
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unless information in these files change their state to yellow or red. The first file is the 
"colorsys.dat" file which contains the color scheme for the top level categories of 
telemetry points. The file format is 

temp red 
power red 

After analysis is complete, this information is read and applied to the telemetry color 
scheme for user display. 

The second color file is "colors.dat", which contains the color scheme for each 
particular telemetry point that went out of range. The format for this file is 

rxtemp 2 red 
cell 12 yellow 
batcur 2 red 

This file is also read after analysis by the telemetry display routines, so that the user 
has a quick indication of problems in the telemetry information. 

The last telemetry file is the "teldata.dat" file. This file contains all pertinent 
information about each data point as the system determined from the telemetry file. This 
includes the highest and lowest values found, the latest value, and the number of times that 
the telemetry point was outside of normal operating parameters. Each data point has its 
own significance. The highest and lowest values gives the user an idea of how close the 
telemetry point may be to its limits, or how far it exceeded them. The counter gives an 
idea as to how often the point was out of limits. If the number is very low, it may have 
been a single event upset, or some inconsequential event. A high count rate would alert 
the user that the system has exceeded the limits, and action needs to be taken. The order 
of the points is pre-determined, so a procedural display algorithm will be easy to 
implement. 

There are also outputs that are appended to previous data that can aid the user in 
determining the current state, and trends. The first is "lifeval.dat" which is the lifetime 
values for each point. This file contains every reading of each telemetry point and 
associated time tag. This file is in a space deliminated file format that can be easily 
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imported into a spread sheet or plotting routine for analysis. The next two files look at 
periodic characteristics. The rules determine the high and low value per orbit, and write 
those to "hivals.dat" and "lovals.dat". These two files strip away the transient readings 
and can aid in determining if the long term trends are getting closer to the limits, and if a 
prediction can be made as to when these points may exceed their operating limits. This 
will make specific trends much easier to notice. If certain components are getting hotter 
over a period of time, then the highest point per orbit will quickly point this out, while the 
constant temperature fluctuations that occur every orbit may obscure the long term trends. 

The last file to be written are the conclusions that the program reached. The first is 
problems in the telemetry asserted in the limit checking and system operation routines. 

The "prob.dat" file contains all systems and readings that are not correct. The last file is 
the decisions file, "dec.dat" which contains all of the decisions reached by the expert 
system. A much more in depth written explanation of each rule and a rule 
interdependency matrix can be found in Appendix A. Appendix B contains the code 
developed so far in this project, which is not in its final form. 
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IX. GROUND STATION SOFTWARE DESIGN 



A. REQUIREMENTS 

The PANSAT Ground Station will be responsible for all tasks that will be associated 
with the daily operations of the satellite, as well as the primary contingency station in case 
unforeseen circumstances require special commanding from the ground. The ground 
station will be used by the Space Systems Academic Group, as well as students at the 
Naval Post Graduate School. The use of the system by untrained students requires that 
the user interface with the satellite be as simple to understand as possible without losing 
any of the capabilities required to effectively operate the satellite. 

The ground station needs to have the capability to do several different operations in 
order to maintain the satellite system. First of all, the ground station will have to be able 
to track the satellite. This will require the station to have an accurate internal clock, and 
the ability to update it from an accurate source. The ground station also requires up to 
date ephemeris information on the satellite. Once the station knows the position of the 
satellite, and its predicted rise and set times, the station must then be able to control the 
antenna so that communications can be established. 

Once the computer determines the satellite is in sight, then it must be able to 
establish a communications link. Since the satellite will be in a receive only mode, the 
ground computer will have to initiate the communications link. Once the link has been 
established, then the ground station must be able to transmit information, both commands 
and files, to the spacecraft, and receive information from the spacecraft. This information 
must also be displayed to the user in a logical manner, so that it can be quickly interpreted. 
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B. GROUND STATION DESIGN 



The ground station will use one computer for controlling the antenna with a Kansas 
City Tracker. With one computer responsible for antenna pointing and satellite tracking, 
the user will be able to also display the satellite's current location, so the position of the 
antenna can be verified. The satellite's ephemeris will be updated via modem with data 
from the NPS amateur radio club bulletin board. The internal clock can also be updated 
by modem or radio to ensure accurate tracking. 

A second computer has the satellite communications software as diagrammed in 
Figure 9-1. This program is menu driven to quicken and simplify use. The spacecraft 
operations are separated into three distinct phases. During the first phase the user sets up 
the ground station to prepare for the next satellite pass. The second phase is when the 
satellite is in view, and the ground station is communicating. The last phase is the post 
processing routines. 
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Figure 9-1. Top Level Ground Station Software Block Diagram 



All of the commands performed in the pre-pass phase can also be performed during 
the satellite pass, but the limited time the satellite is in view discourages this use. Upon 
starting the ground software, it first sets up the display menus so that the user can begin 
operations. The modem and terminal node controller (TNC) are setup with configuration 
files. The user can edit a script for use on the next pass. It is written in a ASCII based 
text editor, and then compiled to ensure that all commands are understood and verified. 
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Files are also selected for transfer. The program automatically checks those selected for 
PANSAT file headers. If there is not one, the user is queried to supply the needed 
information. Once a script is selected, and the files are processed for transfer, the ground 
station is ready to connect to the spacecraft. A default script can also be used so not 
every pass will have to be monitored by ground personnel. 

Once the ground station is in contact with the satellite, it will send a connect packet 
and establish a communication link. The ground station and satellite conclude the 
operations that were being performed the last time the satellite was in view. If the satellite 
had not yet completely downloaded a file, then the ground station will request to satellite 
to fill the holes in the partially downloaded files. Similarly, the ground station request and 
continues to upload any files that were only partially uploaded on the previous pass. Once 
these operations are completed, the script can be executed, or the user can send 
commands as he wants. For every pass, the ground station should at least perform all 
necessary functions to check on the 'health' of the satellite, and download or upload any 
messages. 

Once the telemetry is downloaded, it is automatically sent to the CLIPS subroutines 
to determine the satellite state. The telemetry file is translated into format so the Artificial 
Intelligence routines can quickly access the information, search for conclusions from the 
data, and output its analysis to the user. Once the analysis is complete, the problems and 
decisions, as well as telemetry information can be accessed from the main menu, and 
displayed in a color coded windows format. The color coded telemetry categories will 
quickly cue the user to any problems in the satellite. A green indication signifies that the 
parameter is within its normal range for all operations. A yellow telemetry point indicates 
that an anomalous value that exceeded the normal operating range of the satellite, and 
could eventually impact the satellite's operation. A red indication means that a telemetry 
point has exceeded a critical threshold. The occurrence had endangered the spacecraft, 
and interferes with proper operation. Corrective action must be taken immediately, if not 
already performed by the autonomous nature of the satellite. The ground station will have 
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pull down menus to access the subcategories telemetry points as shown in Figure 9-2. 
Only the master ground station will have the ability to receive all telemetry files. Civilian 
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Figure 9-2, Main Page Layout 

users will only be able to download the current telemetry file. The satellite telemetry will 

be divided into categories and displayed as TEMPERATURE, POWER, SCOS, and BAX. 

If a user wants amplifying information on a particular system, he will click the mouse 
on the major category, and the telemetry will be displayed in a window, vrith the 
description and color coded limits as illustrated in Figure 9-3. Any telemetry point can be 
selected for display by clicking the mouse on subsystem, which will bring up another 
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Figure 9-3, Telemetry Subsystem Display with Selected Telemetry Point 

window that identifies the parameter, its latest value, high and low values, the limits, and 

the number of times the point has failed that criteria. 

Another section of the main screen will display the raw communications that are 
going on with the satellite and will show the commands that are being sent and received by 
the satellite. The visual cue of the satellite link will also insure the proper operation of the 
automated software. 

By selecting a menu option, the user will be able to send commands to the satellite. 
The commands are divided and accessed in three categories. Super User commands, 
general commands, and ground commands, shown in Figure 9-4. The super user 
commands are those that affect the configuration of the satellite. While general commands 
are other functions the ground station can have the satellite perform, but they do not alter 
the satellite. Neither of these categories are available to the civilian user. The last set of 
commands are the ground commands. These are the file transfer and mail commands that 
all civilian users will be able to use. 
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Figure 9-4, Satellite Commanding Menus Layout 



During the post pass phase, the data from the recent and past passes can be further 
analyzed, and stored. The data is also archived on a regular basis. 

The other type of ground station will be designed for the civilian user. He can use 
either software offered by NFS, or may be able to use others commercially available that 
implement PACSAT FTLO if the NFS version is compatible. These packages will not 
have the passwords needed to access the stored telemetry, or send commands to the 
spacecraft. It will allow the amateur full access to transfer files in the store and forward 
capability. The satellite will also have recent telemetry for those wishing to download that 
information. The spread spectrum transmitter will also be required. A kit will be available 
either through NFS, or a civilian company. With easily available software and hardware, 
the FANSAT should have numerous customers wanting to use its services. 



C. FILE TRANSFER 

When a file is to be transmitted to or from the satellite, the File Transfer Level 0 
(FTLO) communication protocol, as seen in Figure 9-5, is used. It was developed by Jeff 
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Ward and Harold E. Price to be used on Pacsat. When a FTLO packet is transmitted to 
the spacecraft, it has an information field of 0 to 2047 bytes, and a two byte headei that 
indicates the number of bytes in the information field and the packet type. The type of 
information field uses binary 0 to 3 1, except for 18-29, to call subroutines onboard the 
satellite. The following information field can then be used by the satellite operating 
system.(Ref 17) 




Figure 9-5, File Transfer Block Diagram 



D. ADD PANSAT FILE HEADER 

The file header added onto the front of every file transmitted to the spacecraft carries 
pertinent information for the satellite to properly carry out its functions. The file header 
consists of several fields, of which only a few are supplied by the user. When the user 
selects a file for upload, the ground station executes the file header routine on the file 
selected. The program prompts the user for file type and compression used. It then 
queries the user for the destination callsigns. The last step is for the user to supply the 
title of his message, and keywords so others can decide if they would like to download 
that file. Once the information is supplied, is it appended onto the front of the file along 
with other information added by the computer. The computer added fields include flag, 
length of file, source, priority, mail name and extension, number of destinations, title 
length, key words length, and checksums for the header and body. 
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When the ground station is linked to the satellite and requests to send a mail file, the 
computer first checks the PANSAT file header for validity. It then sends the upload 
request to the satellite along with the total size of the file. The satellite then determines if 
there is room in the mailbox for that size of a file. If so, it sends the ground station a 
number which is then used to identify the message. With this message number, the ground 
station can then upload the file. Once the message is received by the satellite, it puts 
additional information into the header. This includes body offset, download count, upload 
time, expire time, and updates the header checksum. When the ground station downloads 
a file, the computer will then strip the file of the PANSAT file header and save it on the 
hard disk. 



E. TELEMETRY SUBSYSTEM 

The telemetry system will have several different phases before it can be analyzed by 
the ground station user. The satellite digital control system will control multiplexers 
which are connected to A/D converters which read the various temperature, voltage, and 
current probes throughout the spacecraft. These values will be read into memory as a 
hexadecimal, unsigned value. The different sensors can be polled at different rates which 
can be set from the ground, depending upon the demands of the subsystems that require 
the information. The polling will also be conducted at regular intervals, and stored into a 
file. The format of the file will have the time that the sample was taken at, followed by 
the value of each telemetry point in order. This file will be binary and must be interpreted 
by the ground station. This file can then be transmitted to the ground station over the 
communications link just as any other file would be transmitted. The satellite also keeps in 
memory the latest telemetry points taken, and these too can be transmitted down to the 
user. The files will have a PANSAT file header added to the beginning before 
transmission, so that the ground station will know that the file contains telemetry 
information, and where the information is located. Once the ground station receives the 
telemetry file, each data point needs to be converted into a measured value according to 
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the equations that govern the sensors. The data is then used in the A, I. software so that 
vital statistics can be determined and presented to the user. 

Once the ground station has converted the raw data into a usable format, the 
PANSAT telemetry analysis tool can then be used to print problems and solutions to the 
screen, or to a file. From the analysis, there can be several different types of 
recommendations. The first type is that the user can then command the spacecraft to 
reconfigure the satellite to operate in a mode that is unaffected by the subsystem that is 
giving the bad telemetry. Another possibility is that the operations of the satellite can be 
changed so that it is less affected by the telemetry points exceeding limits. The last 
possibilities are that the problem cannot be overcome, and the user can only monitor the 
situation, or the exceedance is the actual operational limits of the spacecraft, and the limits 
should be changed to accommodate. 
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X. SPACECRAFT COMMANDING 



One most important aspect of the ground station will be the ability to send 
commands to the spacecraft that can affect the configuration and operations, as well as 
perform trivial housekeeping functions. For most subsystem functions, the software 
onboard the spacecraft must be able to autonomously operate the spacecraft. If situations 
arise where an action must be performed or risk the loss of the satellite, then the vehicle 
itself must be able to determine any action to be performed, and command itself These 
events are and decisions are stored in the spacecraft's event log, which can be downloaded 
and verified for proper operation. 

A problem arises that not all situations can be predicted, so not all solutions can be 
known beforehand. To aid in this situation, the ground station must be able to command 
the spacecraft with all of the same commands that the spacecraft has as its own 
capabilities. The ability to command the spacecraft will also aid in troubleshooting the 
spacecraft and determine possible malfunctions in the system. The ground station will also 
be able to command the satellite to use different subsystems to insure that the redundant 
systems are still operational if desired. 

There will be several different sets of commands that will be used. The first set will 
be those that can be used by all users; the NFS ground station, and the civilian users. 

These will be the basic commands to read mail, send mail, and download recent telemetry. 
These commands will be will comply with already existing FTLO formats in wide use by 
amateur satellites. The only difference will be in the stations' program to put the proper 
PANSAT file header information onto the front of the file. Currently, the PACSAT file 
header protocol adds extra unneeded information that the PANSAT file header will omit. 
This primary reason is to shorten the overall file length. 

The next sets of commands will be those that only the main ground station can 
execute. These will be broken into two categories. The first will be general housekeeping 
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commands. These will include the ability to purge mail, add or delete bulletins, download 
recent and stored telemetry, and other trivial tasks. 

The last set of commands will be those that alter the configuration of the spacecraft, 
or command it to perform certain functions. These commands are known as Super User 
Commands, and will only be executed by authorized personnel. These commands include 
the ability to switch processors, DCS's, batteries, and load software. These commands 
can be used only if the correct password is used, and the computer will verify with the 
user that these commands are what the user wants to perform. These commands will also 
be executed in hexadecimal format. An advantage to this capability is that unauthorized 
users will be less likely to decode the commands that can manipulate the spacecraft in 
ways that we don't want them to be able. 

There are several steps in sending a command to the spacecraft, diagrammed in 
Figure 10-1. When a command is selected, the computer verifies with the user that it is 
the proper command. The next step is to send the packet to the ground-based spacecraft 
simulator. This is an operational mockup of the satellite, which is in the same 
configuration as the ground station expects the satellite to be in. The ground simulator 
echoes back the command, then executes it. The ground station then verifies that the 
simulator echoed back the proper command, and executed it correctly. Once all of these 
steps have been successfully accomplished, then the command can be sent to the 




Figure 10-1, Spacecraft Commanding Block Diagram 
In order to send a command to the satellite, it must be sent to a particular application 
on the spacecraft. The FTLO protocol sends its information packets to PANSAT-1 where 
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-1 indicates the subsystem identification (SSID) which is application address on the 

satellite used by BAX. The commands to the satellite will be sent to PANSAT-2, which is 

the application for interpreting commands. The information sent to the command 

interpretation routine includes a one byte header that tells the satellite how large the 

packet is. Each command uses two bytes, the modifiers use one b)^e, and callsigns use 1 2 

b)^es. The largest size for the command set is 1 5 bytes, so only one byte is needed to 

count total number of bytes in the command. A packet for a ground control command like 

READ CUR TEL would then be 20B or in binary, 

count command 
0002 00001011 

Similarly, a packet for a subsystem command DISCH BATT \A would be 341 or in binary 

count command modifier 
0011 00110100 0001 

If the satellite receives a subsystem command, it first checks that the user has 
already sent the SUPER command with proper password. If not, the satellite responds 
with an error message. If the command is valid, it transmits the interpreted command and 
waits for verification from the ground station. Once the satellite receives verification on 
the command that it interpreted, then it will execute the command, and transmit 
compliance. The list of commands is in Appendix C, while the binary formats are not 
included to keep the distribution of this thesis unlimited. 
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XI. CONCLUSIONS AND FURTHER STUDY 



The automatic analysis of telemetry saves the ground station operator from the 
monotonous task of sorting through and analyzing the vast amounts of telemetry that are 
received from the satellite. By storing the project engineers' knowledge, the ability for 
inexperienced users to understand the health of the satellite is dramatically improved. 
PANSAT also has many students who work on the project and leave, and project 
engineers who will move onto other projects once the satellite becomes operational. The 
ability to retain the corporate knowledge is essential in providing continuity in the 
program. 

From this point, there is still much work to be accomplished. The satellite is 
entering the testing phase, where the operational limits and procedures become more 
defined. As this happens, rules can be added to the knowledge base to keep the A. I. 
portion up to data with the actual configuration of the satellite. The coding for the ground 
station software can also begin as the interface between the controllers and satellite are 
tested. The A.I. code also needs to be imbedded in the C procedural code, where 
significant changes can occur. Instead of writing all decisions and problems to file, they 
can be presented to the user as soon as they are discovered through subroutines called by 
the rule set. As the program stands, it asks the user for the name of the telemetry file. In 
the final form, there are two different versions of the rule set. One will have the full 
capabilities, including the ability to append data to the lifetime and high and low values 
data files. This rule set will be used automatically when the ground station receives a new 
telemetry file from the spacecraft. The interface is automatic, and not seen by the user. 
Another version of the rule set is used to analyze past data sets. This rule set does not 
have the ability to append data to existing files, which would corrupt the data files by 
doubling old data out of sequence. 
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APPENDIX A. 



Explanation of rules for PANSAT telemetry analysis 

The following paragraphs are quick explanations of each rule in the rule set. The 
number of each rule is used in following matrices of rule interdependence. The program 
can be run either in a windows environment, or DOS. After entering the operating 
environment, the user must type (load prog.clp) to load the constructs into memory. A 
(reset) must be commanded next, which clear the facts and asserts (initial-fact), which 
must exist for the program to execute. The program can then be executed with a (run) 
command. The program asks for a file name that contains the telemetry data, "data.clp" 
has data to test the program. Upon completion, all files are closed with a (close) 
command so that other applications can access those files. 

1 . defhile open-file 

This operation is performed first because of the initial-fact which is automatically 
asserted with a (reset) command. The rule then asks the user for the file name that 
contains the telemetry data. In the final form, then telemetry file will be included, and the 
input will be transparent to the user. The file is then found and opened. The name of the 
file is saved for later use, and the initial-fact is removed so that the rule will not fire again. 
The rule also opens the output files, so that other rules may write or append data to them. 
Several facts are asserted to initiate the operation of several other rules. 

2. defhile read_parameter 

Here, the rule makes sure the file containing the current configuration file is open, 
and ready to be read which is asserted by either the open-file, or read_setting. It then 
reads the data of the configuration system and retracts the facts that fired the rule. 

3. defiaile read_setting 
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If the configuration file is open, and the subsystem name has been read by 
read_parameter, and it is not the end of file marker, then the rule reads in the subsystem 
selected, saves the information, and deletes the fact that fired the rule. 

4. defrule eof_setting 

If the configuration file is open, and the subsystem name has been read by 
read_parameter, and it is the end of file marker, then the rule closes the configuration file, 
and retracts the facts that fired the rule. 

5. defrule read-data-header 

The rule checks for the open data file name, and if the telemetry point name is to be 
read by a fact asserted by either open-file or end-of-line. The new telemetry point name is 
then read, as well as the next field that determines the number of those telemetry points. 
The telemetry name is then stored, along with the number of points. A counter is then 
initialized, and the fact that fired the rule is retracted. 

6. defhile read-data 

This is the only rule that has the salience set. It is so that the rule will only fire if it is 
the only rule on the agenda list. This is vitally important to the operation of the program. 
Since this rule deletes old telemetry points each time it reads in a new one, then is rules get 
under the read-data rule in the agenda list, they may no longer be valid after the rule 
deletes the old telemetry point. By setting the salience, this ensures that all rules 
associated with each telemetry point will fire before that point is deleted. If the points 
were not deleted, then the program would quickly fill up the available RAM, and the 
operation would slow down immensely as the data is stored in the hard disk. 

The rule checks for the open data file name and an old data point. The next points 
name is found, and it is checked to make sure that it is not an end of file marker or time 
tag. The number of points is then found, and checked against the counter to make sure 
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that not all of the telemetry points for that subsystem have been read. The next telemetry 
point is then read and saved, and the old telemetry point is deleted. The point is also 
asserted as the latest point to begin the search for the latest value of each telemetry point. 
The rule also asserts facts to start the out count rule in determining if an error is always 
happening. The counter is then incremented for the next read-data rule firing. The last 
two operations are to append the data points onto the life time value file, and assert a fact 
so that the limit checking only occurs once per telemetry point. 

In a CLIPS program, the inference engine matches facts to rules, and only fires a 
rule once for a given set of facts that matches the left hand side. In the limit checking 
rules, a counter in incremented. Each time the rule fires, it deletes the old counter and 
asserts a new counter. This new counter is then a new fact that satisfies the left hand side. 
If another fact from a different routine were not asserted here, and retracted in the limit 
checking rules, then the limit rule would continue indefinitely, incrementing the counter 
continuously, which puts the program into an infinite loop. 

7. defhile read-time 

The program checks for open data file name, and finds the old number of telemetry 
points, counter, time fact, and time tags. It fires on assertions made in read-data-header. 
Then the new time is read, and the all old telemetry system information is deleted. It also 
asserts facts to save the time tag, and fire the read-data-header rule. The rule then prints a 
carriage return line feed to the life time values files to keep it in usable format. 

8. defhile end-of-line 

The current telemetry name is found from read-data-header, and checked to ensure 
the end of file has not been reached. The total number of points and counter is found and 
compared. If the counter is equal, then it has already read all of the data points, and the 
end of the telemetry data line has been reached. This causes the counter and number of 
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points and system read to be deleted, and the next telemetry data line can be read since 
read-data-header uses a fact asserted in this routine. 

9. defrule end-of-file 

The old total number of points, counter, and open data file name are found. The 
telemetry point from read-data-header is checked to see if the end of file marker has been 
read. If the program has reached the end of the data file, then the telemetry information 
and point, open data file fact and end of file point are deleted, and the data file is closed. 

A fact is asserted that the file is now closed to be used in other rules. 

10. defrule start_counter 

This rule initialized a counter to determine the number of times that a telemetry point 
is out of limits. A telemetry point is found, and if a counter does not exist yet that is 
associated with that telemetry point, then one is made. This counter is used in all of the 
limit checking rules. 

1 1 . defrule save_battery_current 

This rule saves the battery current so that it is not deleted before it can be used with 
the solar cell current telemetry point. Otherwise, the read-data rule would delete the data 
point, and it could never be compared. 

12. defrule save_cell_current 

This rule is very similar to the save_battery_current since the two need to be used 
concurrently in other rules. 

13. defrule in_sun "Check to see if the satellite is in the sun" 

The solar cell current is found and checked to see if the cells are supplying 
significant power to the spacecraft bus. If it is, then the satellite is in the sun using 
primarily solar power. 

14. defhile in_eclipse "Check to see if the satellite is in eclipse" 
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The battery current is found and checked to see if the battery is discharging. Then 
the same time tagged solar cell current is found to see if it is supplying significant power. 

If the power is coming from the batteries, then the satellite is in eclipse and that fact is 
asserted and time tagged. 

15. defhile exceed_power_budget 

In this case, the battery current is found, and tested to see if it is supplying significant 
power. A solar cell current is also found and tested if it too is supplying significant power. 
If both of the power supplies are giving power to the spacecraft, then the satellite must be 
in the sun, as has been found using in sun, but also, the requirements of the spacecraft 
exceed the ability of the solar panels to supply all needed power. This means that the 
spacecraft is operating in a negative power budget. This rule recommends to fiilly check 
out the power system, and consider changing spacecraft operational capabilities when it 
finds that the power budget has been exceeded. 

16. defrule delete_old_power_facts 

When the read-data rule is completed, and the data file is closed, no more telemetry 
points will be read. This rule deletes all of the battery temperature and current points as 
well as the solar cell currents that were saved, since they will no longer be needed. 

17. defrule save_battery_temp 

This rule is very similar to the save_battery_current since the battery temperature 
and voltage need to be used concurrently in other rules. 

18. defhile save_battery_volt 

This rule is the same as to the save_battery_temp since the battery temperature and 
voltage need to be used concurrently in other rules. 

19. defhile batt_charged 
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This nile determines if the batteries are tlilly charged, and the time that they are first 
fully charged in each orbit. By linearizing the suppliers graph voltage and temperature, the 
equation of a line will determine if the batteries are at or above the voltage threshold for a 
given temperature. If so, the rule determines that the batteries are fully charged. 

20. defrule bat_temp_increase 

When a battery is fully charged, continued charging causes the temperature of the 
battery to increase, since the energy is not used for increasing the electric potential of the 
battery. This rule determines how much the temperature rises after is has been decided 
that the batteries are fully charged. The fact that the batteries are charged is found, and 
the battery temperature with the same time tag, so the temperature at completed charging 
is known. Another battery temperature fact is found. The facts are then tested to ensure 
that the second temperature occurred within one orbit after the first reading, and the 
second point is higher than the first temperature. The rule then finds the temperature 
change and saves it as a new fact. 

21. defhile largest_change 

Since there are several readings after the batteries are charged, there will be several 
temperature differences. This rule finds two temperature difference facts in the same orbit 
and retracts the smaller difference. Eventually, only the largest temperature increase will 
remain. 

22. defrule latest_eclipse 

Here, the rule finds two times in eclipse, and determines which one is later. It then 
deletes the earlier time in eclipse. 

23. defrule latest_sun "Find latest time in sun for current orbit" 

The computer finds two times that the satellite is in the sun, and determines which is 
later. It then deletes the earlier time in the sun. 
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24. defmle leave eclipse 

If there is an in eclipse fact followed by a later (in sun time) fact, then the satellite 
just left the earth's shadow. In this case, the rule deletes the (in eclipse time) fact, and 
stores the time that the satellite left the earth's shadow as a new fact. 

25. defrule find jatest 

If this rule finds two latest facts as initiated by the read-data rule, it will delete the 
earlier fact. Eventually, only one fact remains, and is output in the "teldata.dat" file once 
all data has been read. 

26. defhile solar_cells_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a solar cell temperature point is searched for and checked to see if it is below the 
lower temperature range. The counter for the cell is also found. If it is out of limits, then 
the rule saves the telemetry point, temperature, and time tag. The red telemetry colors for 
this condition are saved, the (new fact) is deleted, and the out of range counter is 
incremented. 

27. defiule solar cells cool 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a solar cell temperature point is searched for and checked to see if it is above the 
lower temperature range, and below the lower normal operating temperature. The 
counter for the cell is also found. If it is out of limits, then the rule saves the telemetry 
point, temperature, and time tag. The yellow telemetry colors for this condition are saved, 
the (new fact) is deleted, and the out of range counter is incremented. 

28. defiule solar_cells_warm 
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This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a solar cell temperature point is searched for and checked to see if it is above upper 
normal operating temperature, and below the upper temperature range. The counter for 
the cell is also found. If it is out of limits, then the rule saves the telemetry point, 
temperature, and time tag. The yellow telemetry colors for this condition are saved, the 
(new fact) is deleted, and the out of range counter is incremented. 

29. defrule solar_cells_hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a solar cell temperature point is searched for and checked to see if it is above the 
upper temperature range. The counter for the cell is also found. If it is out of limits, then 
the rule saves the telemetry point, temperature, and time tag. The red telemetry colors for 
this condition are saved, the (new fact) is deleted, and the out of range counter is 
incremented. 

30. defhale bat_volt_too_low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery voltage point is searched for and checked to see if it is below lower voltage 
range. The counter for the battery voltage is also found. If it is out of limits, then the rule 
saves the telemetry point, temperature, and time tag. The red telemetry colors for this 
condition are saved, the (new fact) is deleted, and the out of range counter is incremented. 
This rule determines that whenever the battery voltage gets too low, the power system 
should be checked out, and recommends either reconditioning the batteries, or changing 
operations so that the batteries do not drain as much during eclipse. 
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3 1 . defrule bat volt low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery voltage point is searched for and checked to see if it is above lower voltage 
range, and below the lower normal operating voltage. The counter for the battery voltage 
is also found. If it is out of limits, then the rule saves the telemetry point, temperature, 
and time tag. The yellow telemetry colors for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. The same recommendations are 
made as for bat_volt_too_low. 

32. defiule bat_volt_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery voltage point is searched for and checked to see if it is above upper normal 
operating voltage, and below the upper voltage range. The counter for the battery voltage 
is also found. If it is out of limits, then the rule saves the telemetry point, temperature, 
and time tag. The yellow telemetry colors for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. If the battery voltage gets too high, 
the rule recommends trickle charging the batteries, which limits the charging current. 

33. defitile bat_volt_too_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery voltage point is searched for and checked to see if it is above upper 
maximum voltage range. The counter for the battery voltage is also found. If it is out of 
limits, then the rule saves the telemetry point, voltage, and time tag. The red telemetry 
colors for this condition are saved, the (new fact) is deleted, and the out of range counter 
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is incremented. If the battery voltage gets too high, the rule recommends trickle charging 
the batteries, which limits the charging current. 

34. defrule bat_temp_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery temperature point is searched for and checked to see if it is below the lower 
temperature range. The counter for the battery temperature is also found. If it is out of 
limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. 

35. defrule bat_temp_cool 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery temperature point is searched for and checked to see if it is above the lower 
temperature range, and below the lower normal temperature operating range. The counter 
for the battery temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry colors for this condition 
are saved, the (new fact) is deleted, and the out of range counter is incremented. 

36. defhile bat temp warm 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery temperature point is searched for and checked to see if it is above upper 
normal temperature range, and below the upper temperature range. The counter for the 
battery temperature is also found. If it is out of limits, then the rule saves the telemetry 
point, temperature, and time tag. The yellow telemetry colors for this condition are saved. 
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the (new fact) is deleted, and the out of range counter is incremented. The rule 
recommends trickle charging the batteries at a reduced current flow. 

37. defrule bat temp hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery temperature point is searched for and checked to see if it is above the upper 
temperature range. The counter for the battery temperature is also found. If it is out of 
limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. The rule recommends trickle charging the batteries at a 
reduced current flow. 

38. defrule battery_current_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery current point is searched for and checked to see if it is above the upper 
normal current range and below the maximum current range. The counter for the battery 
current is also found. If it is out of limits, then the rule saves the telemetry point, current, 
and time tag. The yellow telemetry colors for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. 

39. defrule battery_current_too_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a battery current point is searched for and checked to see if it is above the upper 
maximum current range. The counter for the battery current is also found. If it is out of 
limits, then the rule saves the telemetry point, current, and time tag. The red telemetry 
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colors for this condition are saved, the (new fact) is deleted, and the out of range counter 
is incremented. 

40. defrule tx_current_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter current point is searched for and checked to see if it is above the upper 
normal current range and below the maximum current range. The counter for the 
transmitter current is also found. If it is out of limits, then the rule saves the telemetry 
point, current, and time tag. The yellow telemetry colors for this condition are saved, the 
(new fact) is deleted, and the out of range counter is incremented 

41. defrule tx_current_too_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter current point is searched for and checked to see if it is above the 
maximum current range. The counter for the transmitter current is also found. If it is out 
of limits, then the rule saves the telemetry point, current, and time tag. The red telemetry 
colors for this condition are saved, the (new fact) is deleted, and the out of range counter 
is incremented 

42. defrule bus_volt_too_low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus voltage point is searched for and checked to see if it is below the minimum 
voltage range. The counter for the bus voltage is also found. If it is out of limits, then the 
rule saves the telemetry point, voltage, and time tag. The red telemetry colors for this 
condition are saved, the (new fact) is deleted, and the out of range counter is incremented 
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43. defhile bus_volt_low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus voltage point is searched for and checked to see if it is above the minimum 
voltage range and below the normal operating voltage. The counter for the bus voltage is 
also found. If it is out of limits, then the rule saves the telemetry point, voltage, and time 
tag. The yellow telemetry colors for this condition are saved, the (new fact) is deleted, 
and the out of range counter is incremented 

44. defrule bus_volt_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus voltage point is searched for and checked to see if it is above the normal 
operating voltage and below the maximum voltage range. The counter for the bus voltage 
is also found. If it is out of limits, then the rule saves the telemetry point, voltage, and 
time tag. The yellow telemetry colors for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. The bus voltage is directly tied to 
the battery charging rate, so if the bus voltage is out of limits, this rule recommends to 
trickle charge the battery to limit the charging current flow. 

45. defhile bus_volt_too_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus voltage point is searched for and checked to see if it is above the maximum 
voltage range. The counter for the bus voltage is also found. If it is out of limits, then the 
rule saves the telemetry point, voltage, and time tag. The red telemetry colors for this 
condition are saved, the (new fact) is deleted, and the out of range counter is incremented. 



74 



The bus voltage is directly tied to the battery charging rate, so if the bus voltage is out of 
limits, this rule recommends to trickle charge the battery to limit the charging current 
flow. 

46. defrule bus_temp_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus temperature point is searched for and checked to see if it is below lower 
temperature range. The counter for the bus temperature is also found. If it is out of 
limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. 

47. defhile bus_temp_cool 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus temperature point is searched for and checked to see if it is above lower 
temperature range, and below the lower normal operating temperature. The counter for 
the bus temperature is also found. If it is out of limits, then the rule saves the telemetry 
point, temperature, and time tag. The yellow telemetry colors for this condition are saved, 
the (new fact) is deleted, and the out of range counter is incremented. 

48. defrule bus_temp_warm 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus temperature point is searched for and checked to see if it is above the upper 
normal operating temperature, and below the upper temperature range. The counter for 
the bus temperature is also found. If it is out of limits, then the rule saves the telemetry 
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point, temperature, and time tag. The yellow telemetry colors for this condition are saved, 
the (new fact) is deleted, and the out of range counter is incremented. 

49. defrule bus_temp_hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a bus temperature point is searched for and checked to see if it is above the upper 
temperature range. The counter for the bus temperature is also found. If it is out of 
limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. 

50. defrule tx_volt_too_low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter voltage point is searched for and checked to see if it is below the 
minimum voltage range. The counter for the transmitter voltage is also found. If it is out 
of limits, then the rule saves the telemetry point, voltage, and time tag. The red telemetry 
color changes for this condition are saved, the (new fact) is deleted, and the out of range 
counter is incremented. A high transmitter bus voltage is directly tied to the electrical 
power system bus, so there is most likely a problem in the over power system. The rule 
recommends checking the power system for voltages out of range. 

51. defrule tx_volt_low 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter voltage point is searched for and checked to see if it is below the normal 
voltage range and above the minimum voltage range. The counter for the transmitter 
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voltage is also found. If it is out of limits, then the rule saves the telemetry point, voltage, 
and time tag. The telemetry color changes for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. 

52. defhale tx_volt_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter voltage point is searched for and checked to see if it is above the normal 
operating voltage and below the maximum voltage range. The counter for the transmitter 
voltage is also found. If it is out of limits, then the rule saves the telemetry point, voltage, 
and time tag. The yellow telemetry colors for this condition are saved, the (new fact) is 
deleted, and the out of range counter is incremented. 

53. defrule tx_volt_too_high 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter voltage point is searched for and checked to see if it is above the 
maximum voltage range. The counter for the transmitter voltage is also found. If it is out 
of limits, then the rule saves the telemetry point, voltage, and time tag. The red telemetry 
colors for this condition are saved, the (new fact) is deleted, and the out of range counter 
is incremented. 

54. defrule tx_temp_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter temperature point is searched for and checked to see if it is below the 
minimum temperature range. The counter for the transmitter temperature is also found. If 
it is out of limits, then the rule saves the telemetry point, temperature, and time tag. The 
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red telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. The recommendation is made whenever the transmitter 
temperature is low to transmit more often if the power budget allows. 

55. defrule tx_temp_cool 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter temperature point is searched for and checked to see if it is below the 
normal operating voltage range and above the minimum temperature range. The counter 
for the transmitter temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry color changes for this 
condition are saved, the (new fact) is deleted, and the out of range counter is incremented. 

56. defrule tx_temp_warm 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a transmitter temperature point is searched for and checked to see if it is above the 
normal operating temperature range and below the maximum temperature range. The 
counter for the transmitter temperature is also found. If it is out of limits, then the rule 
saves the telemetry point, temperature, and time tag. The yellow telemetry colors for this 
condition are saved, the (new fact) is deleted, and the out of range counter is incremented. 
A recommendation is made for a transmitter that is higher the temperature range may be 
able to be fixed by increasing the attenuation on the transmitted signal, so the transmitter 
will use less power, or switch transmitters. 

57. deftule tx_temp_hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously. 
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then a transmitter temperature point is searched for and checked to see if it is above the 
maximum temperature range. The counter for the transmitter temperature is also found. 

If it is out of limits, then the rule saves the telemetry point, temperature, and time tag. 

The red telemetry colors for this condition are saved, the (new fact) is deleted, and the out 
of range counter is incremented. 

58. defrule rx_temp_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a receiver temperature point is searched for and checked to see if it is below the 
minimum temperature range. The counter for the receiver temperature is also found. If it 
is out of limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. Any time a receiver is below normal operating 
temperatures, a recommendation is made to switch receivers and determine if the 
secondary has any problems. 

59. defiiile rx_temp_cool 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a receiver temperature point is searched for and checked to see if it is above the 
minimum temperature range and below the normal operating temperature. The counter 
for the receiver temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry colors for this condition 
are saved, the (new fact) is deleted, and the out of range counter is incremented. 

60. defrule rx temp warm 
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This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a receiver temperature point is searched for and checked to see if it is above upper 
normal operating temperature, and below the upper temperature range. The counter for 
the receiver temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry colors for this condition 
are saved, the (new fact) is deleted, and the out of range counter is incremented. 

61. defrule rx temp hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a receiver temperature point is searched for and checked to see if it is above the 
upper temperature range. The counter for the receiver temperature is also found. If it is 
out of limits, then the rule saves the telemetry point, temperature, and time tag. The red 
telemetry colors for this condition are saved, the (new fact) is deleted, and the out of 
range counter is incremented. 

62. defrule dcs_temp_cold 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a digital control system temperature point is searched for and checked to see if it is 
below the minimum temperature range. The counter for the DCS temperature is also 
found. If it is out of limits, then the rule saves the telemetry point, temperature, and time 
tag. The red telemetry colors for this condition are saved, the (new fact) is deleted, and 
the out of range counter is incremented. Whenever the DCS is outside of normal 
temperatures, the rules recommend switching DCSs. 

63. defhile dcs_temp_cool 
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This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a digital control system temperature point is searched for and checked to see if it is 
above lower temperature range, and below the lower normal operating temperature. The 
counter for the DCS temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry colors for this condition 
are saved, the (new fact) is deleted, and the out of range counter is incremented. 

64. defrule dcs_temp_warm 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a digital control system temperature point is searched for and checked to see if it is 
above upper normal operating temperature, and below the upper temperature range. The 
counter for the DCS temperature is also found. If it is out of limits, then the rule saves the 
telemetry point, temperature, and time tag. The yellow telemetry colors for this condition 
are saved, the (new fact) is deleted, and the out of range counter is incremented. 

65. defhile dcs_temp_hot 

This rule first determines if a telemetry point has been limit checked earlier by 
finding the (new fact) asserted by read-data. If a point has not been checked previously, 
then a digital control system temperature point is searched for and checked to see if it is 
above the upper temperature range. The counter for the DCS temperature is also found. 

If it is out of limits, then the rule saves the telemetry point, temperature, and time tag. 

The red telemetry colors for this condition are saved, the (new fact) is deleted, and the out 
of range counter is incremented. 

66. defhile edacseu counter 
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The first step in this rule is to find the error detection and correction counter and test 
to determine if too many errors have occurred in the software. EDAC errors are most 
likely caused by radiation or particles striking the internal components of the spacecraft. 
With the error detection and correction, it can detect and correct one error, and detect 
two errors without correction. If the number of errors is large, then the probability of 
getting two errors which are not correctable in the same space greatly increases. The 
RAM wash is a subroutine to read all data in memory, do the error checking and 
correcting, counting all errors, and writes the data back into memory. This rule 
recommends increasing the frequency of RAM wash to lower the number of single event 
upsets in the RAM. 

67. defrule worst case system 

The main telemetry display will only show the color for the worst case of the 
categories subsystems. In every limit checking rule, if the same fact is asserted twice for 
the same system, CLIPS will only keep one assertion. Then only one red and one yellow 
fact at most will remain. In this case, the rule finds two facts for the same set of telemetry 
points, one red and one yellow. It then deletes the yellow case and saves the worst case, 
the red one. If there is only one yellow case, then it will remain as the worst case. 

68. defhtle worst_case_tel_pt 

This rule is very similar to the worst case system, but instead of saving the worst 
case for the system, it is only saving the worst case for each telemetry point. Since at 
different times any telemetry point could be red or yellow, only the red case will remain. 

69. defhile initialize_occurence_problem 

This rule is to start the process of finding when during an orbit a telemetry point 
goes out of limits. If a telemetry point goes out of limits every orbit, this algorithm will 
give the user an idea if it occurs at about the same time every orbit, or if it is not related in 
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any way to the orbital period. The rule finds a telemetry problem and the last time the 
satellite left eclipse and makes a fact of first time the problem occurred. 

70. defrule find_first_occurence 

In this situation, the rule finds two different facts that state the first time a problem 
occurred, and determines which actually occurred first, within the same orbit, and deletes 
the latest occurrence. 

71. defrule initialize_high_and_low_orbit 

In the same manner as the find_first_occurence rules, this set of rules finds the 
highest value per orbit of each telemetry point. The rule first finds a telemetry point that is 
an analog value, not a binary state or counter, and initialized that fact as the high for the 
orbit. This rule also asserts the fact as the highest value to start the search for the highest 
telemetry point in the entire file. 

72. defhile find_high_orbit 

The next step in the process is to find two high values of the same telemetry point 
that occurred within the same orbit, and delete the lower value. The high value is then 
written to a file at the end of each orbit with the save_hi_and_low_data rule. 

73. defrule find_highest 

Like the find_high_orbit routine, this rule searches for the highest value of each 
telemetry point in the file for presentation to the user. The highest value will give the user 
a quick idea of how close the telemetry point is to its limits. The highest facts have 
already been asserted, so this rule finds two highest facts, and deletes the data point with 
the lower value. 

74. defiule find_low_orbit 

Just like the find_high_orbit, this rule finds two low values of the same telemetry 
point that occurred within the same orbit, and deletes the higher value. 
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75. defrule findjowest 

Like the find_low_orbit routine, this rule searches for the lowest value of each 
telemetry point in the file for presentation to the user. The lowest value will give the user 
a quick idea of how close the telemetry point is to its limits. The lowest facts have already 
been asserted, so this rule finds two lowest facts, and deletes the data point with the higher 
value. 

76. defrule check_configuration 

This rule uses the configuration file that contains the information about the satellite's 
settings. This rule compares the ground's settings with the satellites to determine if the 
satellite has autonomously changed its configuration. Two facts are found, the 
configuration fact and the telemetry fact for the same system. The settings for that system 
are then compared. If they are not the same, then the fact that the satellite has changed its 
configuration is asserted. 

77. defhile del_config 

Once the telemetry data file is closed, there are no more settings to be compared, so 
the configuration facts are deleted. 

78. defhile del_high 

Once the telemetry data file is closed, the high data points per orbit are still in 
memory. Since the orbit will not be completed in the telemetry data, these are of no use 
since it is not known of these actually are the high values for the entire orbit. Therefore, 
this rule deletes all unwanted high facts. 

79. defrule del jow 

Once the telemetry data file is closed, the low data points per orbit are also still in 
memory. Since the orbit will not be completed in the telemetry data, these are of no use 
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since it is not known of these actually are the low values for the entire orbit. Therefore, 
this rule deletes all unwanted low facts. 

80. defrule constant_out_counter 

Once a telemetry point has exceeded a limit, it may either stay out of limits, or fall 
back within the limits. This rule will determine if the telemetry point stayed out of limits 
once it exceeded those limits. 

This accomplished by initializing a counter that fires once an orbit after a telemetry 
point has exceeded its limits. If there is a limit exceedance and a counter hasn't been 
started yet, then a counter is started. 

8 1 . defrule out_count 

This rule continues the constant_out_counter. The fact is fired by the data point that 
is being read by read-data. If a data point is read that has a counter already, then the 
counter is incremented and the fact that fired the rule is deleted. 

82. defrule check_counts 

Once the telemetry data file is closed, this rule checks on the counters to determine if 
the telemetry point stayed out of limits once it exceeded them. It gets two counters, the 
count that incremented each time the data point was read after it went bad, and the 
counter of the number of times that the telemetry point was out of limits. If these two 
counters are the same, then the telemetry point stayed out of limits once it exceeded the 
limits the first time. The counter since the first occurrence is deleted so that 
save_telemetery_data can fire. This prevents save_telemetery_data from deleting the 
counters before this rule can use them. 

83. defhile not_always_out 

This rule does the same process as out_count, except that it sees if the counters are 
different. If they are different, then the telemetry point did not stay out of parameters, and 
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the counter since the first occurrence is deleted. This allows the save_telemetery data 
rule to fire. 

84. defrule del_next 

The read-data rule asserts rules so that the out_count routine can work. Once the 
telemetry data file is closed, these facts are no longer needed. This routine determines that 
the file is closed, and deletes the facts asserted by read-data 

85. defrule save_first_problems 

The problems with the spacecraft are written to an ASCII file so that they may be 
presented to the user in the graphical interface. When the telemetry data file is closed, a 
problem fact is found that was also the first time that the problem occurred. The two facts 
are then combined to inform the user that a problem occurred, the time tag, and the time 
into the orbit the problem occurred. The information is written to the "problem.dat" file 
and deleted from memory. 

86. defrule save_problems 

Problems that were not the first in its orbit are also saved to the problem file. In this 
case, the rule finds a fact, and determines that there is not a corresponding first time fact. 
The information is then written to the "problem.dat" file and deleted from memory. 

87. defrule save decisions 

The decisions that the program arrives at are written to an ASCII file for display to 
the user once the telemetry data file has been completely read. If the telemetry data file is 
closed, then the rule writes all decisions that are recommended by the program to the 
"decide.dat" file. The decisions are then deleted from memory. 

88. defrule save_telemetry_colors 

Once the telemetry file is closed, the telemetry point colors are written to the ASCII 
file "colors.dat". This information is used to change the colors displayed to the user. If a 
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telemetry point is not specified by the file to be red or yellow, then the user interface 
assumes that the telemetry point is in the green. Once the color facts are written to file, 
they are removed from memory. 

89. defrule save_system_colors 

Once the telemetry file is closed, the telemetry system colors are written to the 
ASCII file "colorsys.dat". This information is used to change the colors of the major 
categories of telemetry displayed to the user. If a telemetry system is not specified by the 
file to be red or yellow, then the user interface assumes that the system is in the green. 
Once the color facts are written to file, they are removed from memory. 

90. defrule save_hi_and_low_data 

Here, the high and low data points per orbit are written to the "hivals.dat" and 
"lovals.dat" files. When there are two "sun" with times tags facts, then the satellite has 
completed an orbit. The rule then deletes the earlier "sun" fact to start the process again. 
The high and low values for each data point are then found and written to file. The first 
value in each line of the file is the time tag for the beginning of the orbit. Since each high 
and low value will occur at a different time for each telemetry point, only the orbit time is 
kept so that only two files need be used. The time tag is then followed by the high or low 
value for that orbit. The facts are written to the files in the same order as the telemetry 
stream. 

9 1 . defrule save_telemetery_data 

The telemetry data is saved to a file "teldata.dat" so that the information can be 
displayed to the user through the telemetry display interface. This rule fires after the 
telemetry data file is closed, and the count_out rule no longer needs the data since it is 
deleted in this step. The rule finds all of the facts concerning each telemetry points 
highest, lowest, and latest values. It also collected each points' counter for the number of 
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times that it was out of limits. It then writes all of the information to file in an orderly 
fashion. The teldata.dat file will be in the same order as the telemetry stream. The first 
row will be the first telemetry point read in the file. The first number is the highest value 
that the telemetry point had in the file. The next is the lowest value. The third number is 
the counter of the number of times that the point was out of limits. The last number in 
each line is the latest value of that telemetry point. All of the data written to file is then 
retracted from memory. 
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The following matrices show the dependence of the rules on each other. Across the 
top of the matrix represents that left hand side of the rule, while down the left side 
represents the right hand side of the equation. The X's mark the assertions from the right 
hand side of the rules that cause the left hand sides to become satisfied. 
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APPENDIX B. 



Code Developed for PANSAT Telemetry Analysis 



(defrule open-file "Open the telemetry and configuration file" 
(initial-fact) ;Do this operation first 

=> 



(retract 0) 

(printout t "Name of file to read 
(bind ?name (read)) 

(open ?name data "r") 

(open "setting.dat" setting "r") 
(open "lifevals.dat" lifeval "a") 
(open "hivals •daf* hivals "a") 
(open "lovals.dat" lovals "a") 
(open "problems.dat" problems "w 
(open "decide.dat" decide "w" ) 
(open "colors.dat” colors "w") 
(open "colorsys.dat" colorsys "w 
(open "teldata.dat" teldata "w") 
(assert (read-file ?name) ) 

( assert ( nextline ) ) 

(assert (time 0)) 

(assert (tel not 111)) 

(assert (setting open)) 

( assert ( nextval ) ) 

) 

(defrule read_parameter "Read the 
(setting open) 

?next<- ( nextval ) 



; Prevent firing again 
crlf) ;Ask file to read 
;Get file name 
;Open the data file 
;Open the configuration file 
;Open lifetime data file 
;Open high value/orbit file 
;Open low value/orbit file 
;Open problem file 
;Open decision file 
;Open color file 
") ;Open color file 

;Open telemetry data file 
;Save name of file 
;Set up to read file 



subsystem name" 

; Ensure config file open 
;Get address of nextval 



(bind ?set (read setting)) 
(assert (set ?set)) 

(retract ?next) 

) 

(defrule read_setting "Read the 
(setting open) 

?setting<-( set ?set ) 

(set “EOF) 

=> 

(bind ?val (read setting)) 
(assert (config ?set ?val)) 

( assert ( nextval ) ) 

(retract ?setting) 

) 

(defrule eof_setting "Read the 
?set<-( setting open) 

?end<-(set EOF) 



;Read subsystem name 
; Assert name 
; Remove nextval 

subsystem selected" 

•Ensure config file open 
;Get address of set fact 
; Check not EOF marker 

;Read the subsystem selected 
;Assert subsystem selected 
; Read__parameter fires again 
; Retract old subsystem name 

EOF marker" 

; Ensure config file open 
;Find EOF fact 
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;Find nextval fact 



?next<- ( nextval ) 

=> 

(close setting) 

(retract ?next) 

(retract ?end) 

(retract ?set) 

) 

(defrule read-data-header 
(read-file ?name) 

?next <- (nextline) 



; Close configuration file 
; Delete nextval fact 
; Delete EOF fact 



"Read the name of telemetry point” 
; Check for open file 
;Get address of fact 



(bind ?var (read data)) 
(bind ?num (read data)) 
( assert ( pt ?var ) ) 

( assert ( tot ?num) ) 

( assert ( count 1 ) ) 
(retract ?next) 



;Read telemetry point name 
;Read number of points 
; Store the point name 
; Store the number of points 
; Start counter 
; Retract to end 



"Read 

- 100 )) 



) 

(defrule read-data 
(declare (salience 
(read-file ?name) 
?olddata<- ( tel 
(pt ?var) 

(pt "EOF) 

(pt "time) 

(tot ?num) 

(time ?tim) 

?countval <- (count ?val) 
(test (<= ?val ?num) ) 

=> 



the data values” 

;Allows all rules 
; Check for open file 
?varold ?valold ?dataold ?timold);del old data 

;Get point name 
; Check to see not EOF 
; Check to be not time tag 
;Get number of points 
;Get time tag 
;Get counter 
; Check counter 



) 



(bind ?data (read data) ) ;Read to data point 

(retract ?olddata) ; Delete old data point 

(assert (tel ?var ?val ?data ?timn;Save new data 



(assert (latest ?var ?val ?data 
(assert (next ?var ?val)) 

(bind ?val (+ ?val 1)) 

(retract 7countval) 

(assert (count ?val)) 

(printout lifeval ” ” ?data) 
(assert (new fact)) 



?tim)); Start latest search 

; Start constant out routine 
; Increment counter 
; Delete old counter 
; Save new counter 
; Write to lifetime data file 
;Stop firing on limit checks 



(defrule read-time "Read the time tag from the file” 



(read-file ?name) 

?oldtot <- (tot ?num) 
?oldcount <- (count ?val) 
?oldtime <- (time ?tim) 
7pttime <-(pt time) 



; Check for open file 
;Get old number of points 
;Get old counter 
;Get old time tag 
;Get time fact 



=> 



(bind 7t (read data)) 
(retract 7oldtime) 
(retract 7pttime) 
(retract 7oldtot) 



;Read new time tag 
; Delete old time tag 
; Delete point 

; Delete old total of points 
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{ retract Poldcount ) 

( assert ( nextline ) ) 

(assert (time ?t)) 

(printout lifeval crlf ?t) 

) 

(defrule end-of-line "Read to 
?pt <- (pt ?var) 

(pt *EOF) 

Ptotal <- (tot ?num) 
Pcountval <- (count ?val) 
(test (> ?val ?num) ) 



; Delete old counter 
; Prepare for next line 
;Save time tag 

; Write time to lifetime file 

end of line'* 

;Get point name 
;Check not end of file 
;Get old total of points 
;Get old counter 
; Check counter more points 



(retract Pcountval) 
(retract Ptotal) 
(retract Ppt) 

( assert ( nextline ) ) 



) 

(defrule end-of-file 
Ptot <- (tot Pnum) 

Pcount <- (count Pval) 
Preadfile <- (read-file Pname) 
Ppteof <- (pt EOF) 



; Delete old counter 
; Delete old number of points 
; Delete old telemetry name 
; Prepare to read next line 

Have reached end of file marker" 

;Get old total of points 
;Get old counter 
;Get data file name 
;Get end of file 



Polddata <- (tel Pvar2 Pnum2 Pdata2 Ptime2) ;Get old telemetry 
=> 

(retract Preadfile) 



( retract Polddata ) 
(retract Ppteof) 
(retract Ptot) 

(retract Pcount) 

(assert (done-reading) ) 
(close data) 



; Delete file open fact 
; Delete old telemetry point 
; Delete EOF data point 
; Delete old number of points 
; Delete old counter 
; Store finished reading file 
;Close data file 



) 

(defrule start_counter "Start a counter for number of problems" 
(tel Pvar Pnum Pdata Ptime) ;Get telemetry point 

(not (counter Pvar Pnum Pcount)) ;Check no counter 

=> 



(assert (counter Pvar Pnum 0)) ;Start counter 

) 

(defrule s ave_battery_current 

(tel batcur Pval Pamp Pmin) ;Get battery current 

=> 

(assert (power batcur Pval Pamp Pmin));Save in different form 

) 

(defrule save_cell_current 

(tel cellcur Pval Pamp Pmin) ;Get cell current 



(assert (power cellcur Pval Pamp Pmin));save in different form 

) 

(defrule in_sun "Check to see if the satellite is in the sun" 
(power cellcur Pval Pconp Pmin) ;Get battery current 

(test (> pamp .01)) ;Check to see if cells lit 
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(assert (in_sun ?min) ) 

) 

(defrule in_eclipse "Check to see 
(power batcur ?val ?amp 7min) 
(test (>= ?amp .01)) 

(power cellcur ?val ?amp2 ?min) 
(test (<= ?amp2 .01)) 

=> 

(assert (in_eclipse ?min) ) 

) 

(defrule exceed__power_budget 
(power batcur ?val ?amp ?min) 
(test (>= ?amp .01)) 

(power cellcur ?val ?amp2 ?min) 
(test (> ?amp2 .01)) 



; Satellite in sun 

if the satellite is in eclipse" 
;Get battery current 
; Check battery discharging 
;Get cell current 
; Check that cells not lit 

; Satellite in eclipse 



;Get battery current 
; Check battery discharging 
;Get cell current 
; Check that cells are lit 



(assert (pt power_budget 1 exceeded 7min) ) 

(assert (dec check_power_system) ) 

(assert (dec do_not_transmit_during_eclipse ) ) 

) 

(defrule delete_old_power_f acts 

(done -reading) ;No more data 

7old<-( power 7var 7val 7amp 7min) ;Get old power fact 



(retract 7old) ; Delete old power fact 

) 

( defrule save_battery_temp 

(tel battemp 7val 7 temp 7min) ;Get battery temp 

=> 



(assert (power battemp 7val 7temp 7min));Save in different form 

) 

( defrule save_battery_volt 

(tel batvolt 7val 7volt 7min) ;Get battery volt 

=> 



(assert (power batvolt 7val 7volt 

) 

(defrule batt_charged 

(power battemp 7val 7temp 7min) 
(power batvolt 7val 7volt 7min) 
(test (> (- 7volt (* -.01 7temp) ) 



7min));Save in different form 



;Get battery temp 
;Get battery voltage 
9.8)) ;Test to fit line 



(assert (event battery 7val charged 7min) ) 

) 

(defrule bat_temp_increase 

(firs time bat 7val charged 7min 7after);Get battery charge time 



(power battemp 7val 7temp 7min) 
(power battemp 7val 7temp2 7min2) 
(test (< 7min 7min2)) 

(test (< (- 7min2 7min) 3600)) 
(test (< 7temp 7temp2)) 



;Get temperature 

;Get later temperature 

; Check in same orbit 
; Check temp increase 



=> 



(bind 7change (- 7temp2 7temp) ) ;Save temp increase 
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(assert ( temp_change_charge Pchange ?min2 ) ) 

) 

(defrule largest_change 

( temp_change_charge Pchange ?min) ;Get a temperature change 
?less<-( temp_change_charge ?change2 ?min2);Get second change 
(test (< (- ?min2 Pmin) 3600)) ;Same orbit 
(test (> Pchange Pchange2)) ;Which is less 



(retract Pless) 

) 

(defrule latest_eclipse "Find the 
(in_eclipse Pmin) 

Psec <- (in_eclipse Pminl) 
(test (> Pmin Pminl)) 

=> 

(retract Psec) 

) 

(defrule latest_sun "Find latest 
(in_sun Pmin) 

Psec <- (in_sun Pminl) 

(test (> Pmin Pminl)) 

=> 

(retract Psec) 

) 

(defrule leave_eclipse 
(in_sun Pmin) 

Pleave <- (in_eclipse Pmin2) 
(test (> Pmin Pmin2 ) ) 



;Del less change 

last point in eclipse for period" 
;Get old time in eclipse 
?Get new time in eclipse 
;Make sure at later time 

; Delete earlier eclipse time 

time in sun for current orbit" 

;Get old sun time 
;Get second sun time 
; Check if sun time later 



; Delete earliest sun time 

"Check satellite has left earth shadow" 
;Get in sun fact 
;Get in eclipse fact 
j Check in sun after eclipse 



(retract Pleave) ; Delete eclipse fact 

(assert (sun Pmin)) ;Store time left shadow 

) 

(defrule find_latest "Find same data points and delete earliest" 
(latest Pvar Pval Pdata Ptim) 

Pear ly<-( latest Pvar Pval Pdata2 Ptim2) 

(test (> Ptim Ptim2)) ; Check for latest time 



(retract Pearly) 

) 

(defrule solar_cells_cold "Check if 
Pnew<-(new fact) 

(tel cell Pnum Ptemp Pmin) 

(test (< Ptemp -30)) 

Pbad<-( counter cell Pnum Pcount) 



solar cells within limits" 
;Make sure rule hasn’t fired 
;Get solar cell temp point 
; Check if below lower temp 



(assert(pt cell Pnum cold Pmin)) ;Below limits, save problem 
(assert (color_system temp red)) ?Make color of telemetry red 
(assert (color cell Pnum red)) 

(bind Pcounter (+ Pcount 1)) ; Increment counter 

(assert (counter cell Pnum Pcounter)) 

(retract Pbad) 

(retract Pnew) 
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) 

(defrule solar_cells_cool 
?new<-(new fact) 

(tel cell ?num ?temp ?min) 

(test (< ?temp 0)) 

(test (>= ?temp -30)) 

?bad<-( counter cell ?num ?count) 

=> 

(assert(pt cell ?num cool ?min)) 
(assert (color_system temp yellow)) 
(assert (color cell ?num yellow)) 
(bind ?count (+ ?count 1)) 

(retract ?bad) 

(retract ?new) 

(assert (counter cell ?num ?count) ) 

) 

(defrule solar_cells_warm "Check if 
?new<-(new fact) 

(tel cell ?num ?temp ?min) 

(test (> ?temp 50)) 

(test (<= ?temp 140)) 

?bad<-( counter cell ?num ?count) 

=> 

(assert(pt cell ?num warm ?min) ) 
(assert (color^system temp yellow)) 
(assert (color cell ?num yellow)) 
(bind ?count (+ ?count 1)) 

(retract ?bad) 

(assert (counter cell ?num ?count)) 
(retract ?new) 



Check solar cells within limits" 

;Make sure rule hasn't fired 
;Get solar cell temp point 
; Check if above lower temp 
; Check if below normal temp 



; Below limits, save problem 
; Color of telemetry red 

; Increment counter 



solar cells within limits" 
;Make sure rule hasn't fired 
;Get solar cell temp point 
; Check above normal temp 
; Check below upper max temp 



; Above limits, save problem 
; Color telemetry yellow 

; Increment counter 



) 



hot 



(defrule solar_cells_ 

?new<-(new fact) 

(tel cell ?num ?temp ?min) 

(test (> ?temp 140)) 

?bad<-( counter cell ?num ?count) 

=> 

(assert(pt cell ?num hot ?min) ) 
(assert (color^system temp red)) 
(assert (color cell ?num red)) 

(bind ?count (+ ?count 1)) 

(retract ?new) 

(retract ?bad) 

(assert (counter cell ?num ?count) ) 



"Check if solar cells within limits" 

;Make sure rule hasn't fired 
;Get solar cell temp point 
; Check above max temp 



;Save problem 
;Make color of 



telemetry red 



; Increment counter 



) 



low 



(defrule bat_volt_too_ 
?new<-(new fact) 

(tel batvolt ?num ?volt 
(test (< ?volt 10)) 



'•check battery voltage within limits" 
;Make sure rule hasn't fired 
?min) ;Get battery voltage point 

; Check below min volt range 



=> 



?bad<-( counter batvolt ?num ?count) 

► 

(assert(pt batvolt ?num too-low ?min) ) ;Save problem 
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(assert (color_system power red)) ;Make color of telemetry red 
(assert (color batvolt ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter batvolt ?num ?count) ) 

(retract ?new) 

(assert (dec check_power_system) ) 

(assert (dec recondition_batteries ) ) 

(assert (dec change_operations ) ) 

) 

(defrule bat_volt_low "Check battery voltage within limits" 

?new<-(new fact) ;Make sure rule hasn’t fired 

(tel batvolt ?num ?volt ?min) ;Get battery voltage point 

(test (< ?volt 11.5)) ;Check below min normal volt 

(test (>= ?volt 10)) ;Check if above min volt 

?bad<- (counter batvolt ?num ?count) 

=> 

(assert(pt batvolt ?num low ?min) ) ;Below limits, save problem 
(assert (color_system power yellow)) ;Color of telemetry red 
(assert (color batvolt ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter batvolt ?num ?count) ) 

(retract ?new) 

) 

(defrule bat_volt_high "Check battery voltage within limits" 
?new<-(new fact) ;Make sure rule hasn’t fired 

(tel batvolt ?num ?volt ?min) ;Get battery voltage point 

(test (> ?volt 13.5)) ; Check above max normal volt 

(test (<= ?volt 15)) ;Check if below max volt 

?bad<-( counter batvolt ?num ?count) 

=> 

( assert (pt batvolt ?num high ?min) ) ;Save problem 

(assert (color_system power yellow) ) ; Color of telemetry red 

(assert (color batvolt ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter batvolt ?num ?count)) 

(assert (dec trickle_charge_batteries ) ) 

) 

(defrule bat_volt_too_high "Check battery voltage within limits" 
?new<-(new fact) ;Make sure rule hasn’t fired 

(tel batvolt ?num ?volt ?min) ;Get battery voltage point 

(test (> ?volt 15)) ;Check above max volt range 

?bad<-( counter batvolt ?num ?count) 

=> 

(assert(pt batvolt ?num too-high ?min) ) ;Save problem 

(assert (color_system power red)) ;Make color of telemetry red 

(assert (color batvolt ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 
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(retract ?new) 

(assert (counter batvolt ?num ?count) ) 

) 

(defrule bat_temp_cold "Check battery temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel battemp ?num ?temp ?min) ;Get battery temp point 

(test (< ?temp -15)) jCheck below min temp range 

?bad<- (counter battemp ?num ?count) 

=> 

(assert(pt battemp ?num cold ?min));Below limits^ save problem 
(assert (color_system temp red)) ;Make color of telemetry red 
(assert (color battemp ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter batvolt ?num ?count)) 

) 

(defrule bat_temp_cool "Check battery temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel battemp ?num ?temp ?min) ;Get battery temp point 

(test (< ?temp -6.7)) ;Check if below normal temp 

(test (>= ?temp -15)) ;Check above min temp range 

?bad<-( counter battemp ?num ?count) 

=> 

(assert(pt battemp ?num cool ?min));Below limits, save problem 
(assert (color^system temp yellow)) ;Color of telemetry yellow 
(assert (color battemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter battemp ?num ?count)) 

) 

(defrule bat_temp_warm "Check battery temp within limits" 

?new<«(new fact) ;Make sure rule hasn't fired 

(tel battemp ?num ?temp ?min) ;Get battery temp point 

(test (> ?temp 26.7)) ;Check if above normal temp 

(test (<= ?temp 50)) ;Check below max temp range 

?bad<-( counter battemp ?num ?count) 

=> 

(assert(pt battemp ?num warm ?min));Above limits, save problem 
(assert (color_system temp yellow)) ;Color of telemetry yellow 
(assert (color battemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter battemp ?num ?count)) 

) 

(defrule bat_temp_hot "Check battery temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel battemp ?num ?temp ?min) ;Get battery temp point 

(test (> ?temp 50)) ; Check above max temp range 

?bad<-( counter battemp ?num ?count) 
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(assert(pt battemp ?num hot ?min) ) ;Above limits, save problem 
(assert (color_system temp red)) ;Make color of telemetry red 
(assert (color battemp ?num red)) 

(bind ?count ( + ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter battemp ?num ?count) ) 

(retract ?new) 

( assert ( dec trickle_charge_batteries ) ) 

) 

(defrule battery_current_high 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel batcur ?num 7 amp ?min) ;Get battery current 

(test (> ?amp 2) ) 

(test (<= ?amp 5)) 

?bad<-( counter batcur ?num ?count) 

=> 

(assert (pt batcur ?num high ?min) ) 

(assert ( color_system power yellow)) ;Color of telemetry yellow 
(assert (color batcur ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter batcur ?num ?count) ) 

(retract ?new) 

) 

( defrule battery_^current_too_high 

?new<“(new fact) ;Make sure rule hasn't fired 

(tel batcur ?num ?amp ?min) ;Get battery current 

(test ( > ?amp 5 ) ) 

?bad<-( counter batcur ?num ?count) 

=> 

(assert (pt batcur ?num too^high ?min)) 

(assert ( color^system power red)) ;Make color of telemetry red 
(assert (color batcur ?num red)) 

(bind ?count (t ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter batcur ?num ?count) ) 

(retract ?new) 

) 

(defrule tx_current_high 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel txcur ?num ?amp ?min) ;Get transmitter current 

(test (> ?amp 2 ) ) 

(test (<= ?amp 5)) 

?bad<-( counter txcur ?num ?count) 

=> 

(assert (pt txcur ?num high ?min) ) 

(assert (color_system power yellow)) ;Make color of telemetry red 
(assert (color txcur ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter txcur ?num ?count)) 
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(retract ?new) 



) 

(defrule tx_current_too_high 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel txcur ?num ?amp ?min) ;Get transmitter current 

(test (> ?amp 5) ) 

?bad<-( counter txcur ?num ?count) 

=> 

(assert (pt txcur ?num too_high ?min)) 

(assert (color_system power red)) ;Make color of telemetry red 
(assert (color txcur ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter txcur ?num ?count)) 

(retract ?new) 

) 

(defrule bus_volt_too_low "Check bus voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel busvolt ?num ?volt ?min) ;Get bus voltage point 

(test (< ?volt 10)) ;Check if below min volt range 

?bad<-( counter busvolt ?num ?count) 

=> 

(assert(pt busvolt ?num too-low ?min) ) ;Save problem 

(assert (color_system power red)) ;Make color of telemetry red 

(assert (color busvolt ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter busvolt ?num ?count)) 

(retract ?new) 

) 

(defrule bus_volt_low "Check bus voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel busvolt ?num ?volt ?min) ;Get bus voltage point 

(test (< ?volt 11,5)) ;Check below min normal volt 

(test (>= ?volt 10)) ;Check above min volt 

?bad<-( counter busvolt ?num ?count) 

=> 

(assert(pt busvolt ?num low ?min) ) ;Below limits, save problem 
(assert (color_system power yellow)) ;Telemetry color yellow 
(assert (color busvolt ?num yellow)) 

(bind 7count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter busvolt ?num ?count)) 

(retract ?new) 

) 

(defrule bus_volt_high "Check bus voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel busvolt ?num ?volt ?min) ;Get bus voltage point 

(test (> ?volt 13.5)) ; Check above max normal volt 

(test (<= ?volt 15)) ;Check if below max volt 

?bad<-( counter busvolt ?num ?count) 

=> 
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( assert (pt bus volt ?num high ?min)) ;Save problem 

(assert ( color^system power yellow)) ;Color of telemetry yellow 

(assert (color busvolt ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter busvolt ?num ?count) ) 

(assert (dec trickle_charge_busteries ) ) 

) 

(defrule bus_volt_too_high "Check bust voltage within limits" 
?new<-(new fact) ;Make sure rule hasn’t fired 

(tel busvolt ?num ?volt ?min) ;Get bust voltage point 

(test (> ?volt 15)) ;Check above max volt range 

?bad<-( counter busvolt ?num ?count) 

=> 

(assert(pt busvolt ?num too-high ?min)) ;Save problem 

(assert (color_system power red)) ;Make color of telemetry red 

(assert (color busvolt ?num red) ) 

(bind ?count (+ ?count 1)) /Increment counter 

(retract 7bad) 

(retract ?new) 

(assert (counter busvolt ?num ?count)) 

) 

(defrule bus_temp_cold "Check bus temp within limits" 

?new<-(new fact) /Make sure rule hasn’t fired 

(tel bustemp ?num ?temp ?min) /Get bus temp point 

(test (< ?temp -10)) /Check below min temp range 

?bad<- (counter bustemp ?num ?count) 

=> 

( assert (pt bustemp ?num cold ?min))/Save problem 

(assert (color_system temp red)) /Make color of telemetry red 

(assert (color bustemp ?num red)) 

(bind ?count (+ ?count 1)) /Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter bustemp ?num ?count) ) 

) 

(defrule bus_temp_cool "Check bus temp within limits" 

?new<-(new fact) /Make sure rule hasn’t fired 

(tel bustemp ?num ?temp ?min) /Get bus temp point 

(test (< ?temp 0)) /Check if below normal temp 

(test (>= ?temp -10)) /Check above min temp range 

?bad<-( counter bustemp ?num ?count) 

=> 

( assert (pt bustemp ?num cool ?min)) /Below limits, save problem 
(assert (color_system temp yellow)) /Color of telemetry yellow 
(assert (color bustemp ?num yellow)) 

(bind ?count (+ ?count 1)) /Increment counter 

(retract ?bad) 

(assert (counter bustemp ?num ?count)) 

) 

(defrule bus_temp_warm "Check bus temp within limits" 
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?new<-(new fact) 

(tel bustemp ?num ?temp ?min) 

(test (> ?temp 40)) 

(test (<= ?temp 50)) 

?bad<-( counter bustemp ?num ?count) 



;Make sure rule hasn't fired 
;Get bus temp point 
; Check if above normal temp 
; Check if below max temp range 



=> 



( assert (pt bustemp ?num warm ?min) ) ;Save problem 

(assert (color_system temp yellow)) ;Make color of telemetry red 

(assert (color bustemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?new) 

(retract ?bad) 

(assert (counter bustemp ?num ?count) ) 

) 

(defrule bus_temp_hot "Check bus temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel bustemp ?num ?temp ?min) ;Get bus temp point 

(test (> ?temp 50)) ;Check above max temp range 

?bad<-( counter bustemp ?num ?count) 



=> 



;Save problem 

;Make color of telemetry red 



; Increment counter 



(assert(pt bustemp ?num hot ?min)) 

(assert (color__system temp red)) 

(assert (color bustemp ?num red)) 

(bind ?count (+ ?count 1)) 

(retract ?bad) 

(retract ?new) 

(assert (counter bustemp ?num ?count)) 

) 

(defrule tx_volt_too_low "Check tx voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel txvolt ?num ?volt ?min) ;Get tx voltage point 

(test (< ?volt 10)) ;Check below min volt range 

?bad<-( counter txvolt ?num ?count) 

=> 

( assert (pt txvolt ?num too-low ?min) ) ;Save problem 

(assert (color_system power red)) ;Make color of telemetry red 

(assert (color txvolt ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter txvolt ?num ?count) ) 

(retract ?new) 

(assert (dec check_power_system) ) 

) 

(defrule tx_volt_low "Check tx voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel txvolt ?num ?volt ?min) ;Get tx voltage point 

(test (< ?volt 11.5)) ;Check below min normal volt 

(test (>= ?volt 10)) ;Check if above min volt 

?bad<-( counter txvolt ?num ?count) 

=> 

( assert (pt txvolt ?num low ?min)) ? Below limits, save problem 
(assert (color^system power yellow)) ;Color of telemetry yellow 
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(assert (color txvolt ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(assert (counter txvolt ?num ?count)) 

(retract ?new) 



) 

(defrule tx volt high "Check tx voltage within limits" 



?new<-(new fact) 

(tel txvolt ?num ?volt ?min) 

(test (> ?volt 13.5)) 

(test (<= ?volt 15)) 

?bad<- ( counter txvolt ?num Pcount) 



;Make sure rule hasn't fired 
;Get tx voltage point 
; Check above max normal volt 
; Check if below max volt 



=> 



(assert(pt txvolt ?num high ?min) ) ;Above limits^ save problem 
(assert ( color_system power yellow)) ;Telemetry color yellow 
(assert (color txvolt ?num yellow)) 

(bind Pcount (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter txvolt ?num Pcount) ) 

) 

(defrule tx_volt_too_high "Check tx voltage within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel txvolt ?num ?volt ?min) ;Get tx voltage point 

(test (> ?volt 15)) ;Check if above max volt range 

?bad<-( counter txvolt ?num Pcount) 



(assert(pt txvolt Pnum too-high Pmin)) ;Save problem 

(assert (color^system power red)) ;Make color of telemetry red 

(assert (color txvolt Pnum red)) 

(bind Pcount (+ Pcount 1)) ; Increment counter 

(retract Pbad) 

(retract Pnew) 

(assert (counter txvolt Pnum Pcount)) 

) 

(defrule tx_temp_cold "Check transmitter temp within limits" 

Pnew<-(new fact) ;Make sure rule hasn't fired 

(tel txtemp Pnum Ptemp Pmin) ;Get transmitter temp point 

(test (< Ptemp -10)) ;Check if below min temp range 

Pbad<-( counter txtemp Pnum Pcount) 

=> 



(assert(pt txtemp Pnum cold Pmin)) ;Save problem 

(assert (color_system temp red)) ;Make color of telemetry red 

(assert (color txtemp Pnum red)) 

(bind Pcount (+ Pcount 1)) ; Increment counter 

(retract Pnew) 

(retract Pbad) 

(assert (counter txtemp Pnum Pcount)) 

(assert (dec transmit_beacon) ) 

) 

(defrule tx_temp_cool "Check transmitter temp within limits" 

Pnew<-(new fact) ;Make sure rule hasn't fired 



105 



(tel txtemp ?num ?temp ?min) ;Get transmitter temp point 
(test (< ?temp 0)) ;Check if below normal temp 
(test (>= ?temp -10)) ;Check above min temp range 
?bad<“ (counter txtemp ?num ?count) 



(assert(pt txtemp ?num cool ?min)) ;Save problem 

(assert (color_system temp yellow)) ;Color of telemetry red 

(assert (color txtemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter txtemp ?num ?count)) 



) 

(defrule tx temp warm "Check transmitter temp within limits" 



?new<-(new fact) 

(tel txtemp ?num ?temp ?min) 

(test (> ?temp 40)) 

(test (<= ?temp 50)) 

?bad<-( counter txtemp ?num ?count) 



;Make sure rule hasn’t fired 
;Get transmitter temp point 
; Check if above normal temp 
; Check if below max temp range 



=> 



(assert(pt txtemp ?num warm ?min) ) ;Save problem 

(assert (color_system temp yellow)) ;Make color of telemetry red 

(assert (color txtemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter txtemp ?num ?count)) 

) 

(defrule tx_temp_hot "Check transmitter temp within limits" 

?new<-(new fact) ;Make sure rule hasn’t fired 

(tel txtemp ?num ?temp ?min) ;Get transmitter temp point 

(test(> ?temp 50)) ; Check above max temp range 

?bad<-( counter txtemp ?num ?count) 



( assert (pt txtemp ?num hot ?min)) ;Save problem 

(assert (color^system temp red)) ;Make color of telemetry red 

(assert (color txtemp ?num red)) 

(bind ?count (+ ?count 1)) /Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter txtemp ?num ?count)) 

(assert (dec switch_txmitter ) ) 

) 

(defrule rx_temp_cold "Check receiver temp within limits" 

?new<-(new fact) /Make sure rule hasn’t fired 

(tel rxtemp ?num ?temp ?min) /Get receiver temp point 

(test (< ?temp -10)) /Check below min temp range 

?bad<-( counter rxtemp ?num ?count) 



(assert(pt rxtemp ?num cold ?min) ) /Save problem 

(assert (color^system temp red)) /Make color of telemetry red 

(assert (color rxtemp ?num red)) 
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(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter rxtemp ?num ?count)) 



) 

(defrule rx temp cool "Check receiver temp within limits 



?new<-(new fact) 

(tel rxtemp ?num ?temp ?min) 

(test (< ?temp 0)) 

(test (>= ?temp -10)) 

?bad<-( counter rxtemp ?num ?count) 



;Make sure rule hasn’t fired 
;Get receiver temp point 
; Check if below normal temp 
; Check above min temp range 



(assert(pt rxtemp ?num cool ?min) ) ;Save problem 

(assert (color_system temp yellow)) ;Color of telemetry yellow 

(assert (color rxtemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter rxtemp ?num ?count) ) 



) 

(defrule rx_temp_warm "Check receiver temp within limits* 



?new<-(new fact) 

(tel rxtemp ?num ?temp ?min) 

(test (> ?temp 40)) 

(test (<= ?temp 50)) 

?bad<-( counter rxtemp ?num ?count) 



;Make sure rule hasn't fired 
;Get receiver temp point 
; Check if above normal temp 
; Check below max temp range 



=> 



( assert (pt rxtemp ?num warm ?min) ) ;Save problem 

(assert (color_system temp yellow)) ;Color telemetry yellow 

(assert (color rxtemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?new) 

(retract ?bad) 

(assert (counter rxtemp ?num ?count) ) 



(defrule rx_temp_hot "Check receiver 
?new<-(new fact) 

(tel rxtemp ?num ?temp ?min) 

(test (> ?temp 50) ) 

?bad<-( counter rxtemp ?num ?count) 

=> 

(assert(pt rxtemp ?num hot ?min)) 

(assert (color_system temp red)) 

(assert (color rxtemp ?num red)) 

(bind ?count (+ ?count 1)) 

(retract ?bad) 

(retract ?new) 

(assert (counter rxtemp ?num ?count) ) 

(assert (dec switch__rcvr ) ) 

) 

(defrule dcs_temp_cold "Check dcs temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 



temp within limits" 

;Make sure rule hasn't fired 
;Get receiver temp point 
; Check above max temp range 



;Save problem 
; Color of telemetry red 

; Increment counter 
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(tel dcstemp ?num ?temp ?min) ;Get dcs temp point 

(test (< ?temp -10)) ;Check below min temp range 

?bad<-( counter dcstemp ?num ?count) 



;Save problem 
; Color of telemetry red 

; Increment counter 



=> 

(assert(pt dcs ?num cold ?min) ) 

(assert (color_system temp red)) 

(assert (color dcstemp ?num red)) 

(bind ?count (+ ?count 1)) 

(retract ?new) 

(retract ?bad) 

(assert (counter dcstemp ?num ?count)) 

) 

(defrule dcs_temp_cool "Check dcs temp within limits" 

?new<-(new fact) ?Make sure rule hasn't fired 

(tel dcstemp ?num ?temp ?min) ;Get dcs temp point 

(test (< ?temp 0)) ; Check if below normal temp 

(test (>= ?temp -10)) ;Check above min temp range 

?bad<-( counter dcstemp ?num ?count) 

=> 

(assert(pt dcstemp ?num cool ?min) ) ;Save problem 

(assert (color_system temp yellow)) ;Color of telemetry yellow 

(assert (color dcstemp ?num yellow)) 

(bind ?count (+ ?count 1)) ; Increment counter 

(retract ?bad) 

(retract ?new) 

(assert (counter dcstemp ?num ?count)) 

) 

(defrule dcs_temp_warm "Check dcs temp within limits" 



?new<-(new fact) 

(tel dcstemp ?num ?temp ?min) 
(test(> ?temp 40)) 

(test(<= ?temp 50)) 

?bad<-( counter dcstemp ?num ?count) 



;Make sure rule hasn't fired 
;Get dcs temp point 
; Check if above normal temp 
; Check below max temp range 



=> 



(assert(pt dcstemp ?num warm ?min) ) 
(bind ?count (+ ?count 1)) 

(retract ?new) 

(retract ?bad) 

(assert (color_system temp yellow)) 
(assert (color dcstemp ?num yellow)) 
(assert (counter dcstemp ?num ?count) ) 



;Save problem 
; Increment counter 



; Color of telemetry yellow 



) 

(defrule dcs_temp_hot "Check dcs temp within limits" 

?new<-(new fact) ;Make sure rule hasn't fired 

(tel dcstemp ?num ?temp ?min) ;Get dcs temp point 

(test(> ?temp 50)) ;Check above max temp range 

?bad<-( counter dcstemp ?num ?count) 

=> 

(assert(pt dcstemp ?num hot ?min)) ;Save problem 

(assert (color^system temp red)) ;Color of telemetry red 

(assert (color dcstemp ?num red)) 

(bind ?count (+ ?count 1)) ; Increment counter 
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(retract 7bad) 

(retract 7new) 

(assert (counter dcstemp 7num 7count)) 

(assert (dec switch_dcs ) ) 

) 

(defrule edacseu_counter "Check on the frequency of seu in cpu." 
(tel edacseucount 7num 7count 7min) ;Find edac counter 
(test (> 7count 1)) ;Test if greater than limit 



(assert (dec increase_ramwash_frequency ) ) ;Save decision 

) 

(defrule worst_case_system "Save worst colors for system" 

(color_system 7system red) ;Find case where system is red 

7better <- (color_system 7system yellow) ;Find system is yellow 

=> 

(retract 7better) ; Delete yellow case 

) 

(defrule worst_case_tel_pt "Find colors for telemetry and save" 
(color 7telpt 7num red) ;Find where telemetry red 

7better <- (color 7telpt 7num yellow) ;Find telemetry yellow 

=> 

(retract 7better) ; Delete yellow case 



) 

(defrule initialize occurence problem "Start algorithm to find first 



occurence of problem per orbit" 
(pt 7telpt 7num 7prob 7min) 
(sun 7tim) 

(test (>= 7min 7tim) ) 



;Get telemetry problem 
;Get time leaving eclipse 
;Make time before problem 



=> 

(bind 7after (- 7min 7tim) ) ;Determine when 

(assert (firstime 7telpt 7num 7prob 7min 7after)) ;Make first 



(defrule f ind_f irst^occurence "Find the first time that a problem 
occurred" 

(firstime 7telpt 7num 7prob 7min 7after) ;Get firstime fact 
7sec <- (firstime 7telpt 7num 7prob 7minl 7afterl);Get second 
(sun 7time) ;Find time left eclipse 

(test (< 7min 7minl)) ;Check first is earlier 

(test (> 7min ?time)) ;Check first after eclipse 

(test (> 7minl 7time)) ;Check second after eclipse 

=> 

(retract 7sec) 



; Delete later fact 



) 

(defrule initialize_high_and_low_orbit "Find high and low values" 



(tel ?var 7val 7data 7tim) 

(sun ?timl) 

(test (>= ?tim 7timl)) 

(tel "not ?num 7prob 7min) 

(tel "edacseutime 7num 7prob 7min) 
(tel "unauthatt 7num 7prob 7min) 
(tel "authlogins 7num 7prob 7min) 
(tel "attenset 7num 7prob 7min) 



;Get telemetry point 
;Find if left eclipse 
; Check tel pt after eclipse 
;Do not find high value for 
; counters 
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(tel “edacseucountstart ?num ?prob ?min) 

(tel “’RAMwash ?num ?prob ?min) 

(tel "poolbuf f ers ?num ?prob ?min) 

(tel “edacseucount ?num ?prob ?min) 

(tel “verset ?num ?prob ?min) 

(tel "'dcsset ?num ?prob ?min) 

(tel “'modeset ?num ?prob ?min) 

(tel “txset ?num ?prob ?min) 

(tel “rxset ?num ?prob ?min) 

(tel “storageused ?num ?prob ?min) 

(tel “sentmail ?num ?prob ?min) 

(tel “rxdmail ?nuin ?prob ?min) 

(tel “storedmail ?num ?prob ?min) 

(tel “logins ?num ?prob ?min) 

(tel “logouts ?num ?prob ?min) 

(tel “Ulnum ?num ?prob ?min) 

(tel “FRMRnum ?num ?prob ?min) 

(tel “UAnum ?num ?prob ?min) 

(tel “SABMnum ?num ?prob ?min) 

(tel “REJnum ?num ?prob ?min) 

(tel “DMnum ?num ?prob ?min) 

(tel “RNRnum ?num ?prob ?min) 

(tel “DlSCnum ?num ?prob ?min) 

(tel “RRnum ?num ?prob ?min) 

(tel “Inum ?num ?prob ?min) 

(tel “dataout ?num ?prob ?min) 

(tel “datain ?num ?prob ?min) 

(tel “uptime ?num ?prob ?min) 

=> 

(assert (high ?var ?val ?data ?tim) ) ; Initialize high per orbit 
(assert (highest ?var ?val ?data ?tim) ) ; Initialize highest 
(assert (low ?var ?val ?data ?tim) ) ; Initialize low per orbit 
(assert (lowest ?var ?val ?data ?tim) ) ;Initialize lowest 

) 

(defrule f ind_high_orbit ''Find the highest value per orbit of each 

telemetry point** 

(high ?var ?val ?data ?tim) ;Get a high fact 

?lower <- (high ?var ?val ?data2 ?tim2);Get a second high fact 
(test (<> ?tim ?tim2)) ; Check not the same 

(test (>= ?data ?data2)) ; Check first is higher 

=> 

(retract ? lower) ; Delete second fact 

) 

(defrule find_highest **Find the highest value in the file for each 

telemetry point** 

(highest ?var ?val ?data ?tim) ;Get a highest fact 

? lower <- (highest ?var ?val ?data2 ?tim2) ;Get second highest 

(test (<> ?tim ?tim2)) ;Check facts not the same 

(test (>= ?data ?data2)) ;Check first fact is higher 

=> 

(retract ? lower) ; Delete second fact 
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(defrule f ind_low_orbit **Find the lowest value per orbit of each 
telemetry point” 

?lower <- (low ?var ?val ?data ?tim) ;Get a low fact 
Phigher <- (low ?var ?val ?data2 ?tim2) ;Get a second low fact 
(test (<> ?tim ?tim2)) ;Check facts not the same 

(test (<= ?data ?data2)) ;Check first is lower 

=> 

(retract Phigher) ; Delete second fact 

) 

(defrule find_lowest ’’Find the lowest value of each telemetry point” 
(lowest Pvar Pval Pdata Ptim) ;Get a low fact 

Phigher <- (lowest Pvar Pval Pdata2 Ptim2) ;Get second low fact 

(test (<> Ptim Ptim2)) ;Check not the same 

(test (<= Pdata Pdata2)) ;Check first fact is lower 

=> 

(retract Phigher) ; Delete second fact 

) 

(defrule check^conf iguration ’’Check to ensure spacecraft configuration 
is the same as the ground station expects” 

(config Pset Pval) ;Get configuration fact 

(tel Pset Pnum Pact Ptime) ;Get telemetry fact 

(test (<> Pval Pact)) jCheck settings are same 

=> 

(assert (pt Pset Pnum not_conf igured Ptime)) ;config error 

) 

(defrule del_config 

(done-reading) ;No more data 

Pcon<-(conf ig Pset Pval) ;Get config fact 



(retract Peon) ;Delete config fact 

) 

(defrule del_high 

(done-reading) ;No more data 

Phi<-(high Ppoint Pnum Pdata Ptime) ;get high fact 

=> 

(retract Phi) ; Delete high fact 

) 

(defrule del_low 

(done-reading) ;No more data 

Plo<-(low Ppoint Pnum Pdata Ptime) ;Get low fact 



(retract Plo) ; Delete low fact 

) 

(defrule constant_out_counter 

(pt Pvar Pnum Pprob Ptim) ;Find problem fact 
(not (done-reading)) ;More data 

(not (count_out Pvar Pnum Pcount)) ; Problem does not have count 



(assert (count_out Pvar Pnum 0));Start counter 

) 

(defrule ou t_c ou n t 

Pnext<-(next Pvar Pnum) ;Get next fact 
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?oldcnt<-(count_out ?var ?num ?count);If counter, increment 

=> 

(bind ?count (+ ?count 1)) 

(assert (count_out ?var ?num ?count)) 

(retract ?oldcnt) 

(retract ?next) 

) 

(defrule check_counts 

(done-reading) ;No more data 

?cnt<-(count_out ?var ?num ?count);Get count since bad 
(counter ?var ?num ?countbad) ;Get count out of limits 
(test (= ?count ?countbad) ) ; See if same 

=> 

(retract ?cnt) ; Delete old count fact 

(assert (problem ?var ?num constantly_out_limits ) ) 

) 

( defrule not_always_out 

(done-reading) ;No more data 

?cnt<-(count_out ?var ?num ?count) ;Get count since bad 

• (counter ?var ?num ?countbad) ;Get count out of limits 
(test (<> ?count ?countbad) ) ; See if not same 



(retract ?cnt) 

) 

(defrule del_next 

(done-reading) ;No more data 

?next<-(next ?var ?num) ;Get next fact 



(retract ?next) ; Delete next fact 

) 

(defrule save_f irst_problems "Save problems found in telemetry" 
(done-reading) ;Find if data files open 

?prob<-(pt ?var ?val ?data ?tim) ;Get problem fact 
?when<-( f irstime ?var ?val ?data ?tim ?after) 



=> 



(printout problems ?var " " ?val " " ?data " " ?tim " occured first 
time at " ?after " seconds after eclipse" crlf) ;Send file 
(retract ?prob) 

(retract ?when) 

) 

(defrule save_problems "Save problems found in telemetry" 
(done-reading) ;Find if data files open 

?prob<-(pt ?var ?val ?data ?tim) ;Get problem fact 
(not (f irstime ?var ?val ?data ?tim ?after)) 



(printout problems ?var " " ?val " " ?data " " ?tim crlf) 
(retract ?prob) 

) 

(defrule save_decisions "Save decisions determined by rules" 
(done-reading) ;Find if data files open 

?decide<-(dec $?dec) ;Get decision fact 
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(printout decide ?dec crlf ) 
(retract Pdecide) 



;Send to decision file 



(defrule save_telemetry_colors "Save colors determined by rules" 
(done-reading) ;Find if data files open 

?col<-(color ?var ?num ?color) ;Get color fact 

=> 

(printout colors ?var" "Pnum" "?color crlf) ;Send color file 
(retract ?col) 

) 

(defrule save_system_colors "Save colors determined by rules" 
(done-reading) ;Find if data files open 

?col<- ( color_system ?sys ?color) ;Get color fact 



(printout colorsys ?sys* 
(retract ?col) 



'Pcolor crlf) ;Send system color file 



) 

(defrule save_hi_and_low_data 
?early<-(sun ?time) 

(sun ?time2) 

(test (< Ptime ?time2)) 



?cellhil<-( high cell 1 
?cellhi2<-(high cell 2 
?cellhi3<-(high cell 3 
?cellhi4<-(high cell 4 
?cellhi5<- ( high cell 5 
?cellhi6<-(high cell 6 
?cellhi7<-( high cell 7 
?cellhi8<-(high cell 8 ?d8 ?tim8) 
?cellhi9<-(high cell 9 ?d9 ?tim9) 
?cellhilO<-(high cell 10 ?dl0 PtimlO) 
?cellhill<-(high cell 11 ?dll Ptimll) 
?cellhil2<-( high cell 12 ?dl2 ?timl2) 
?cellhil3<-( high cell 13 ?dl3 ?timl3) 
?cellhil4<-(high cell 14 ?dl4 ?timl4) 
?cellhil5<-(high cell 15 ?dl5 ?timl5) 
?cellhil6<-( high cell 16 ?dl6 ?timl6) 
?cellhil7<-(high cell 17 ?dl7 ?timl7 ) 
?batthil<- ( high battemp 1 ?dl8 ?timl8) 
?batthi2<-(high battemp 2 ?dl9 ?timl9) 
?batvhil<-(high batvolt 1 ?d20 ?tim20) 
?batvhi2<-(high batvolt 2 ?d21 ?tim21) 
?batihil<-(high batcur 1 ?d22 ?tim22) 
?batihi2<-(high batcur 2 ?d23 ?tim23) 
?txthil<-(high txtemp 1 ?d24 ?tim24) 
?txthi2<-( high txtemp 2 ?d25 ?tim26) 
?rxthil<- ( high rxtemp 1 ?d26 ?tim26) 
?rxthi2<-(high rxtemp 2 ?d27 ?tim27) 
?busthil<-(high bustemp 1 ?d28 ?tim28) 
?busvhil<-(high busvolt 1 ?d30 ?tim30) 
?celllol<-( low cell 1 ?d32 ?tim32) 
?celllo2<-( low cell 2 ?d33 ?tim33) 



Save high and low per orbit data" 
;Get sun time 

;Get second 
; Determine earliest 
?dl ?timl) 

?d2 ?tim2) 

?d3 ?tim3) 

?d4 ?tim4) 

?d5 ?tim5) 

?d6 ?tim6) 

?d7 ?tim7) 
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?celllo3<-< low cell 3 ?d34 ?tim34) 
?celllo4<-(low cell 4 ?d35 ?tim35) 
?celllo5<-(low cell 5 ?d36 ?tim36) 
?celllo6<-(low cell 6 ?d37 ?tim37) 
?celllo7<-( low cell 7 ?d38 ?tim38) 
?celllo8<-(low cell 8 ?d39 ?tim39) 
?celllo9<-( low cell 9 ?d40 ?tim40) 
?celllolO<-(low cell 10 ?d41 ?tim41) 
?cellloll<-( low cell 11 ?d42 ?tim42) 
?celllol2<-(low cell 12 ?d43 ?tim43) 
?celllol3<-(low cell 13 ?d44 ?tim44) 
?celllol4<-( low cell 14 ?d45 ?tim45) 
?celllol5<-( low cell 15 ?d46 ?tim46) 
?celllol6<-( low cell 16 ?d47 ?tim47) 
?celllol7<-( low cell 17 ?d48 ?tim48) 
?battlol<-( low battemp 1 ?d49 ?tim49) 
?battlo2<-(low battemp 2 7d50 ?tim50) 
?batvlol<-(low batvolt 1 ?d51 ?tim51) 
?batvlo2<-( low batvolt 2 ?d52 ?tim52) 
?batilol<-(low batcur 1 ?d53 ?tim53) 
?batilo2<-(low batcur 2 ?d54 ?tim54) 
?txtlol<-(low txtemp 1 ?d55 ?tim55) 
?txtlo2<-( low txtemp 2 ?d56 ?tim56) 
?rxtlol<-( low rxtemp 1 ?d57 ?tim57) 
?rxtlo2<-( low rxtemp 2 ?d58 ?tim58) 
?bustlol<-(low bustemp 1 ?d59 ?tim59) 
?busvlol<-(low busvolt 1 7d61 7tim61) 



(retract 

(retract 

(retract 

(retract 



"7d26** 

(retract 

(retract 

(retract 



(printout hivals 7time** ”7dl** **7d2** **7d3** **7d4** "7d5** ”7d6** 
•7d8” "7d9** ”7dl0** ”7dll** ”7dl2** **7dl3” •*7dl4” **7dl5” ”) 

(printout hivals 7dl6” •*7dl7” »7dl8‘* *'7dl9»’ **7d20** •*7d21” ” 
d23” ”7d24” ”?d25** ”7d26** ”7d27** ”7d28” ”7d30 crlf) 

7cellhi2) (retract 7cellhi3) 

7cellhi5) (retract 7cellhi6) 

7cellhi8) (retract 7cellhi9) 

(retract 7cellhill) (retract 7cellhil2) 
(retract 7cellhil4) (retract 7cellhil5) 
7cellhil6) (retract 7cellhil7) (retract 7batthil) (retract 
(retract 7batvhil) (retract 7batvhi2) 

(retract 7batihi2) (retract 7txthil) 

(retract 7rxthil) (retract 7rxthi2) 
(retract 7busvhil) 

7time» •*7d32” •*7d33** ”7d34” ”7d35” ••7d36‘* 
**7d38** ”7d39** **7d40” •*7d41** **7d42** •*7d43” **7d44” •*7d45** ”7d46 
”7d48‘* **7d49** **7d50‘* 



7d23” ”7d24” ”7d25* 
(retract 7cellhil ) 
7cellhi4) 
7cellhi7 ) 
7cellhil0) 
7cellhil3) 



( retract 7batihil ) 
(retract 7txthi2) 
(retract 7busthil) 
(printout lovals 



•*7d41** "7d42** ••7d43” 

**7d51» **7d52” •*) 

(printout lovals 7d53” •*7d54** ”7d55” •*7d56” ”7d57** -7d58” 
crlf) ;Send to data file 

(retract 7celllo2) 

(retract 7celllo5) 

(retract 7celllo8 ) 

(retract 7cellloll) 



(retract 7celllol) 

( retract 7celllo4 ) 
(retract 7celllo7) 
(retract 7celllol0 ) 



(retract 7celllo3) 
(retract 7celllo6) 
(retract 7celllo9) 
(retract 7celllol2) 



••7d7*’ 

7d22» 



(retract 
7batthi2 ) 



”7d37»* 

M «?d47“ 

7d59” ”7d61 
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(retract ?celllol3) (retract ?celllol4) (retract ?celllol5) 
?celllol6) (retract ?celllol7) (retract Pbattlol) (retract 
(retract ?batvlol) (retract ?batvlo2 ) 



(retract 
( retract 
( retract 
) 



?batilol ) 
7txtlo2 ) 
?bustlol ) 



( retract ?batvlo2 ) 

(retract ?batilo2) (retract ?txtlol) 
(retract ?rxtlol) (retract ?rxtlo2) 
(retract ?busvlol) (retract ?early) 



?count ) ) 
?dl ?timl) 
?tim2) 
?tim3 ) 
?tim4 ) 
?tim5 ) 
?tim6 ) 
?tim7 ) 
?tim8 ) 
?tim9 ) 



(defrule save_telemetry_data 
( done-reading ) 

(not (count_out ?var ?num 
?cellhil<-( highest cell 1 
?cellhi2<-( highest cell 2 
?cellhi3<-(highest cell 3 
?cellhi4<-( highest cell 4 
?cellhi5<-(highest cell 5 
?cellhi6<-(highest cell 6 
?cellhi7<-(highest cell 7 
?cellhi8<-( highest cell 8 
?cellhi9<-( highest cell 9 
?cellhilO<-(highest cell 
?cellhill<- ( highest cell 
?cellhil2<-(highest cell 
?cellhil3<-( highest cell 
?cellhil4<-( highest cell 
?cellhil5<-( highest cell 
?cellhil6<-(highest cell 
?cellhil7<-(highest cell 17 ?dl7 ?timl7) 
?batthil<-( highest battemp 1 ?dl8 ?timl8) 

?batthi2<-( highest battemp 2 ?dl9 ?timl9) 

batvolt 1 ?d20 ?tim20) 

batvolt 2 ?d21 ?tim21) 

batcur 1 ?d22 ?tim22) 
batcur 2 ?d23 ?tim23) 
?d24 ?tim24) 
?d25 ?tim26) 



;Find if data files oper 
; Constant out done 



?d2 
?d3 
?d4 
?d5 
?d6 
?d7 
?d8 
?d9 
10 
11 
12 

13 

14 

15 

16 
17 



?dl0 

?dll 

?dl2 

?dl3 

?dl4 

?dl5 

?dl6 

?dl7 



?timl0 ) 
?timll ) 
7timl2 ) 
?timl3 ) 
7timl4 ) 
?timl5) 
?timl6 ) 
?timl7 ) 



7batthi2<- ( highest 
?batvhi 1<- ( highest 
7batvhi2<- ( highest 
?batihil<- ( highest 
7batihi2<- ( highest ua 
?txthil<-( highest txtemp 1 
7txthi2<-( highest txtemp 2 
7rxthil<-( highest rxtemp 1 
7rxthi2<-( highest rxtemp 2 
?busthil<- ( highest bustemp 
?busvhi 1<- ( highest busvolt 
?celllol<-( lowest cell 
?celllo2<-( lowest cell 
7celllo3<-( lowest cell 
?celllo4<-( lowest cell 
?celllo5<-( lowest cell 
?celllo6<-( lowest cell 
?celllo7<-( lowest cell 
?celllo8<-( lowest cell 
7celllo9<- ( lowest cell 



7d26 7tim26) 
?d27 7tim27) 

1 7d28 7tim28) 
1 7d30 7tim30) 
7d32 7tim32) 

7d33 7tim33) 

7d34 7tim34) 

?d35 7tim35) 

7d36 7tim36) 

?d37 7tim37) 

7d38 7tim38) 

7d39 7tim39) 

7d40 7tim40) 



(retract 
7battlo2 ) 
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?celllol4<-( lowest cell 14 7d45 ?tim45) 
?celllol5<-( lowest cell 15 ?d46 ?tim46) 
?celllol6<-( lowest cell 16 ?d47 ?tim47) 
?celllol7<-( lowest cell 17 ?d48 ?tim48) 



, 17 ?d48 ?tim48) 

battemp 1 ?d49 7tim49) 
battemp 2 7d50 7tim50) 
batvolt 1 7d51 7tim51) 
batvolt 2 7d52 7tim52) 
batcur 1 7d53 7tim53) 
batCUJT 



7battlol<- ( lowest 
7battlo2<- ( lowest 
7batvlol<-( lowest 
7batvlo2<- ( lowest 

7batilol<«( lowest , 

7batilo2<-( lowest batcur 2 7d54 7tim54) 
7txtlol<-( lowest txtemp 1 7d55 7tim55) 
7txtlo2<-( lowest txtemp 2 7d56 7tim56) 
?rvt-l nlc — / 1 owfifl'h 1 7d57 7tlm57 ) 

7d58 7tim58) 

1 7d59 7tim59) 
1 7d61 7tim61) 
7dc32) 

7dc33) 

7dc34 ) 

7dc35 ) 

7dc36) 

7dc37) 

7dc38 ) 

7dc39 ) 

7dc40) 

7dc41 ) 

7dc42 ) 
7dc43) 
7dc44) 

7dc45 ) 

7dc46 ) 
7dc47) 
7dc48) 

1 7dc49) 

2 7dc50) 

1 7dc51) 

2 7dc52) 
?dc53) 



7txtio^<-( lowest txtemp ^ 

7rxtlol<-( lowest rxtemp 1 
7rxtlo2<-( lowest rxtemp 2 
7bustlol<-( lowest bustemp 
7busvlol<-( lowest busvolt 
7cellcntl<-(counter cell 
7cellcnt2<-(counter cell 
7cellcnt3<-(counter cell 
7cellcnt4<-(counter cell 
7cellcnt5<-(counter cell 
7cellcnt6<-(counter cell 
7cellcnt7<-(counter ^ 
7cellcnt8<-( counter 
7cellcnt9<“( counter 
7cellcntl0<-( counter 
7cellcntll<- (counter 
7cellcntl2<-( counter 
7cellcnt 13<- ( counter 
7cellcntl4<- (counter 
7cellcntl5<-( counter 
7cellcntl6<-( counter 
7cellcntl7<-( counter 
7battcnt 1<- ( counter 
7battcnt2<“ ( counter 
7batvcnt 1<- ( counter 
7batvcnt2<- (counter 
7baticnt 1<- ( counter 
7baticnt2<-(counter batcur 2 7dc54) 
7txtcntl<-(counter txtemp 1 ?dc55) 
7txtcnt2<-( counter txtemp 2 ?dc56) 
7rxtcntl<-( counter rxtemp 1 
7rxtcnt2<-( counter rxtemp 2 
7bustcntl<-(counter bustemp 
7busvcntl<-( counter busvolt 
7ce' '.lastl<-( latest cell 1 
7cc ast2<-( latest cell 
7ce^ wast3<-(latest cell 
7ceiiiast4<-( latest cell 
7celllast5<-( latest cell 
7celllast6<-( latest cell 
7celllast7<-(latest cell 



cell 
cell 
cell 
cell 
cell 
cell 
cell 
cell 
cell 
cell 
cell 
battemp 
battemp 
batvolt 
batvolt 
batcur 1 
batcur 



10 

11 

12 

13 

14 

15 

16 
17 



2 

3 

4 

5 

6 
7 



?dc56) 

7dc57) 

7dc58) 

1 7dc59) 

1 ?dc61) 

7dl32 7timdl32) 
7timdl33) 
7timdl34) 
7timdl35) 
7timdl36 ) 
7timdl37) 
7timdl38) 



7dl33 

7dl34 

7dl35 

7dl36 

7dl37 

7dl38 
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?celllast8<- 

?celllast9<- 



( latest cell 
(latest cell 



?celllastlO<- ( latest 
?celllastll<-( latest 
?cel Hast 12<-( latest 
?celllastl3<-( latest 
?celllastl4<-( latest 
?celllastl5<-( latest 
?celllastl6<-( latest 
?celllastl7<-( latest 
?battlastl<-( latest 
?battlast2<-( latest 
?batvlastl<-( latest 
?batvlast2<-( latest 
?batilastl<-( latest 
?batilast2<-( latest 
?txtlastl<-( latest txtemp 1 
?txtlast2<-( latest txtemp 2 
?rxtlastl<-( latest rxtemp 1 
?rxtlast2<-( latest rxtemp 2 
?bustlastl<-( latest bustemp 
?busvlastl<-( latest busvolt 



8 ?dl39 ?timdl39) 

9 ?dl40 ?timdl40) 



cell 10 ?dl41 ?timdl41) 
cell 11 ?dl42 ?timdl42) 
cell 12 ?dl43 ?timdl43) 
cell 13 ?dl44 ?timdl44) 
cell 14 ?dl45 ?timdl45) 
cell 15 ?dl46 ?timdl46) 
cell 16 ?dl47 ?timdl47) 
cell 17 ?dl48 ?timdl48) 
battemp 1 ?dl49 ?timdl49) 
battemp 2 ?dl50 ?timdl50) 
batvolt 1 ?dl51 ?timdl51) 
batvolt 2 ?dl52 ?timdl52) 
batcur 1 ?dl53 ?timdl53) 
batcur 2 ?dl54 ?timdl54) 
?dl55 ?timdl55) 
?dl56 ?timdl56) 
?dl57 ?timdl57) 
?dl58 ?timdl58) 

1 ?dl59 ?timdl59) 
1 ?dl61 ?timdl61) 



=> 



(printout teldata ?dl*’ **?d32" "?dc32” ”?dl32 crlf ?d2" "?d33” "?dc33* 
•*?dl33 crlf ?d3” ”?d34” ” ) 

(printout teldata ?dc34** '*?dl34 crlf ?d4” '*?d35” '*?dc35** *'?dl35 crlf 
?d5” ••?d36’* "?dc36” ”?dl36) 

(printout teldata crlf ?d6" ••?d37’* *'?dc37’* "?dl37 crlf ?d7" «?d38'* 
••?dc38" "?dl38 crlf ?d8»* **?d39) 

(printout teldata ** ''?dc39” ”?dl39 crlf ?d9” ••?d40” '*?dc40'* **?dl40 
crlf ?dl0” ••?d41" "?dc41'* *’?dl41) 

(printout teldata crlf ?dll'* ”?d42'* '*?dc42" "?dl42 crlf ?dl2" 

•*?d43** '*?dc43” ”?dl43 crlf ?dl3” ”?d44) 



(printout teldata 
crlf ?dl5** "?d46'* 
(printout teldata 
•*?dc48” ”?dl48 crlf 
(printout teldata 
?d20” "?d51” "?dc51” 



” ”?dc44'* "?dl44 crlf 
?dc46” "?dl46 crlf ) 
?dl6” "?d47” •*?dc47" 
?dl8" "?d49” ") 
?dc49” "?dl49 crlf 
'•?dl51 crlf) 



?dl4” ''?d45" "?dc45" "?dl45 
•?dl47 crlf ?dl7*' •*?d48” 
di 9 « "?dc50" ”?dl50 crlf 



•?dl52 crlf ?d22" ”?d53" 



(printout teldata ?d21” "?d52” ”?dc52" 

”?dc53" ”?dl53 crlf ?d23*' "?d54” ”) 

(printout teldata ?dc54’* "?dl54 crlf ?d24** ''?d55” "?dc55” "?dl55 crlf 
?d25” ••?d56” "?dc56'* "?dl56 crlf ) 

?d26” "?d57” •*?dc57** **?dl57 crlf ?d27" "?d58" 

?d28 " ”?d59” ") 

?dc59** "?dl59 crlf 



(printout teldata 
**?dc58” ”?dl58 crlf 
(printout teldata 
crlf) 

(retract ?cellhil ) 
(retract ?cellhi4 ) 
(retract ?cellhi7) 
(retract ?cellhil0) 



( retract ?cellhi2 ) 
(retract ?cellhi5 ) 
(retract ?cellhi8) 
(retract ?cellhill) 



?d30” *'?d61” "?dc61” "?dl61 

( retract ?cellhi3 ) 

(retract ?cellhi6 ) 

(retract ?cellhi9 ) 

(retract ?cellhil2) (retract 



?cellhil3) (retract ?cellhil4) (retract ?cellhil5) (retract 
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(retract ?cellhil7) (retract ?batthil) (retract ?batthi2) 
tvhil) (retract ?batvhi2) 



?cellhil6) 

(retract ?batvhil) 

(retract ?batihil) (retract ?batihi2) 

(retract ?txthi2) (retract ?rxthil) 
(retract ?busthil) (retract ?busvhil) 

(retract ?celllo2) (retract ?celllo3) 

(retract ?celllo5) (retract ?celllo6) 

(retract ?celllo8) (retract ?celllo9) 

?cellloll) (retract ?celllol2) 
(retract ?celllol5) 



(retract ?txthil) 

(retract ?rxthi2) 

(retract ?celllol) 

( retract ?celllo4 ) 

( retract ?celllo7 ) 

, (retract ?celllolO) (retract 

(retract ?celllol3) (retract 
(retract ?celllol6) (retract 

retract ?battlo2) 



?celllol4 ) , 

?celllol7) (retract ?battlol) ( , 

Pbatvlol) (retract ?batvlo2) (retract ?batilol) 

?batilo2) (retract ?txtlol) (retract ?txtlo2) 

?rxtlol) (retract ?rxtlo2) (retract ?bustlol) 
Pbusvlol) (retract ?cellcntl) (retract ?cellcnt2) 
?cellcnt3) (retract ?cellcnt4) 

(retract ?cellcnt7) ( 

(retract ?cellcntlO ) 



(retract ?cellcnt5) (retract 
retract ?cellcnt8) (retract 
retract ?cellcntll) (retract 



( 



(retract 
(retract 
(retract 
(retract 
(retract 
?cellcnt6 ) 

?cellcnt9) , , ^ , 

?cellcntl2) (retract ?cellcntl3) (retract ?cellcntl4) 

(retract ?cellcntl5) (retract ?cellcntl6) (retract ?cellcntl7) 

(retract ?battcntl) (retract ?battcnt2) (retract ?batvcntl) (retract 
?batvcnt2) (retract ?baticntl) (retract ?baticnt2) (retract ?txtcntl) 

cntl ) 

itl) (retract ?busvcntl) (retract 
retract ?celllast3) (retract 

retract ?celllast6) (retract 



?celllast4 ) (retract 
?celllast7 ) (retract 
(retract ?celllastlO) 
(retract ?celllastl3) 
(retract ?celllastl6) 
(retract ?battlast2) 
(retract ?batilastl) 

( retract ? txtlas t2 ) 



?celllast5) , , 

?celllast8) (retract ?celllast9) 

(retract ?celllastll) (retract ?celllastl2) 



?bustlastl) (retract ?busvlastl) 



(retract ?celllastl5) 

( retract ?battlast 1 ) 
(retract ?batvlast2) 

(retract ?batiiast:^) (retract ?txtlastl) 

(retract ?rxtlastl) (retract ?rxtlast2) (retract 
?busvlastl^ 



(retract ?celllastl4 ) 
(retract ?celllastl7 ) 
(retract ?batvlastl) 

( retract ?batilast2 ) 



) 
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APPENDIX C. 



General User Commands 



LIST \B\U\A\CS "callsign" 


transmit list of message and bulletins 
\B list all bulletins 
\U list all messages to user callsign 
\A list all bulletins and messages 
\CS "callsign" list all messages to callsign other than 
users' 

default- list all bulletins and messages to user 
callsign 


READ \B,#\U,#\A\CS "callsign", # 


read messages and bulletins 
\B read all bulletins 
\U read all messages to user callsign 
\A read all bulletins and messages 
\CS "callsign" read all messages to callsign other 
than users' 

,# read only message or bulletin indicated by 
number 

default- read all bulletins and messages to user 
callsign 


DEL\# 


delete messages to user callsign 
\# delete message indicated by number 


SEND \"callsign"\"filename" 


send a message to another user 
\"callsign" callsign of person to receive message 
V'filename" file that contains message to other 
callsign 


LOGON V'callsign" 


initialize communications link with satellite 
\"callsign" official callsign of user 


LOGOFF 


end session with satellite and break communications 
link 


READ TEL 


read current telemetry in memory 
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Ground Control Commands 



Includes those for the general user plus 



DUMP LIST \B\M\A\CS "callsign" 


transmit list of messages and bulletins 

\B list all bulletins 

\M list all messages 

\A list all bulletins and messages 

\CS "callsign" list all messages to callsign 

default- list all bulletins and messages 


DUMP MAIL \B\M\CS "callsign" 


transmit messages and bulletins 

\B send all bulletins 

\M send all messages 

\A send all bulletins and messages 

\CS "callsign" send all messages to callsign 

default- send all bulletins and messages 


POST BULLETIN VTilename" 


post a bulletin for all users to access 
V'filename" file that contains bulletin 


REMOVE BULLETIN \#\T<time> 


remove a bulletin from the spacecraft memory 
\# remove bulletin indicated by number 
\T<time> remove bulletin at specified time 



PURGE MAIL \CS "callsign", #\T<time>\A delete mail 





\CS "callsign" delete mail to callsign 
\T<time> delete mail at specified time 
\A delete all mail 

,# delete message indicated by number 
default- delete ail mail to user callsign 


READ CUR TEL 


read current telemetry in memory 


READ STOR TEL 


download stored telemetry file for analysis 


DEL STOR TEL 


delete information stored in telemetry file 


READ OS PAR 


read the parameters of the operating system, 
pointers, etc. 


READ DATA\# 


read data values in memory location 
\# memory location indicated by number 
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READ CLOCK 


read spacecraft time 


SUPER \<password> 


enter the super user mode 
\<password> is a function of the day of satellite 
operation, will be found in a table format. Allows 
the satellite to execute subsystem commands. 


EXIT 


exit the super user mode. Satellite will no longer 
accept subsystem commands from the ground 
station callsign. 


READ CMDS 


read time tagged command buffer 


READ EVENTS 


read event log 


Subsystem Commands 





These commands require that the user has executed SUPER command. 



CLR CMDS 


clear time tagged command buffer 


CLR EVENTS 


clear event log 


SET CLOCK \<time> 


set the spacecraft clock 

\<time> time to set as soon as received 


LD SOFT V’filename" 


send request to load software with size of code. 
\"filename" file that contains new software, has size 
information in file 

default- load new software and wait for command to 
begin executing new software 


RUN SOFT\"address" 


begin operations using new software 

\”address" beginning address of new software to run 


DEL SOFT\"address”\"size" 


delete software at load address 
\” address" location of beginning of software to be 
deleted 

V'size" size of software to be deleted 
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SET TEL \"filename"\T<time> 



DISCH BATT \A\B 
TRKL BATT \A\B 

CHRG BATT \A\B 

PROC \A\B 

RF\A\B 

MAILBOX \A\B 

MUX\A\B 

MAXTX 



set polling rates for the satellite telemetry 
\'Tilename" file containing the new polling rates 
\T<time> time to implement new polling rates 
default- implement new polling rates as soon as 
received 

Discharge battery A or B. Only one can discharge 
at a time. 

trickle charge battery 

\A\B trickle charge battery A or B as selected 
default- trickle charge both batteries 

charge battery 

\A\B charge battery A or B as selected 
default- charge both batteries 

set processor 

\A\B set processor A or B to be operational 
default- keep same processor operating, send 
which processor is operating 

Set RF selected 

\A\B set rf section A or B to be operational 
default- keep same rf section operating, send 
which rf section selected 



Set Mailbox to be used 
\A\B set mailbox A or B to be operational 
default- keep same mailbox operational, send 
which mailbox selected. 

Set multiplexer selected 
\A\B set multiplexer A or B to be operational 
default- keep same multiplexer operational, send 
which multiplexer selected. 

set current transmitter to max power out 
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MODE \BPSK\SS 



set communications mode 
\BPSK select BPSK mode for communications 
\SS select spread spectrum for communications 
default- keep same communications mode, send 
which communications mode satellite is in 

ATTEN \U set the attenuation on the current transmitter 

\# select the level 1-8 to change the attenuation level 
default- keep attenuation levels the same, send 
attenuation level 
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